perm filename TASK.RND[RDG,DBL]13 blob
sn#620190 filedate 1981-10-19 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00021 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00004 00002 ∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
C00009 00003 ∂18 May 1981 2355-PDT RICK Plan revisions**2
C00034 00004 ∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT> Revisions to CORE project plan thru end of FY 81
C00047 00005 ∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
C00068 00006 ∂15 May 1981 1331-PDT BILL revised plan with task assignments
C00085 00007 ∂TO Rick@Rand-Ai 15:38 20-May
C00098 00008 ∂21-May-81 0802 RICK at RAND-AI reply to your msg
C00121 00009 ∂To BARBARA@Rand-Ai 17:08 21-May
C00135 00010 Msg sent who-knows-when to who-knows-where
C00140 00011 ∂To: (%Rand-Ai Bill, Rick, Wescourt, Barbara, Norm, Mike) 17:24 29-May
C00172 00012 ∂29-May-81 0937 RICK at RAND-AI rll
C00182 00013 ∂29 May 1981 1322-PDT RICK Today's design contributions
C00194 00014 ∂TO Barbara@Rand-Ai 12:36 4-Jun
C00210 00015 ∂ 4 Jun 1981 1036-PDT Keith Wescourt <WESCOURT> Re: Comments on Keith's Proposal
C00212 00016 ∂23-Jun-81 0647 rick at RAND-UNIX overall design and components plus interfaces -- discussion notes
C00226 00017 Discussion with Norm - 19 June 1981
C00235 00018 ∂16 Jul 1981 14:53-PDT preliminary database specifications barbara at RAND-UNIX
C00247 00019 ∂TO Rick@Rand-Ai 13:39 10-Aug
C00252 00020 ∂19 Aug 1981 1351-PDT WESCOURT at RAND-AI Composing match/get specs to retrieval by entry
C00266 00021 ∂28-Sep-81 1554 GREINER at RAND-AI Specs
C00285 ENDMK
C⊗;
∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1238-PST
Russ:
We may eventually constrain, a little but not greatly, the form of the
users' input away from free-form english. We are even considering parsing it
using a good general parser. However, you're on the right track to
think about scanning the input to build conceptual (what you called "keyword")
tags to hang on the sentences. Your task is to enable conceptual labeling,
with arbitarily interesting sources of matching between input and
concepts. To do this, you need to develop a language for describing concepts
and the ways they are realized in inputs. This is different from parsing, in
general, because each distinct user group will speak a different "language"
and will need to emphasize different concepts.
For example, you might want to develop some concepts related to
preferences. Norm has preferences for certain kinds of things and against
others. The relationship between a thing and norm's preference for it
often is the basis for it being included or excluded in the plan. We
need a way to succinctly express such a relationship and have it recognized
in the input so it can be stored and matched (with other inputs, called queries,
which also exhibit it).
Another example, we had something in the concept taxonomy that
barbara prepared having to do with "interesting." However, when we had
a replanning session focused on "make a new route for norm which is changed
as little as necessary but which is less boring than simply repeating the
same route would be," the guy wanted to find anything about "boring" but
couldn't. Find x such that x bores norm is the query. How should we find it?
How can we insure that if it's there, we will actually find it. How can we
express heuristically defined alternative queries that we think will satisfy
the retrieval goal? How should we retain these definitions? Should all
of these automatically be processed for each input and stored with it for
subsequent matching?
e.g., Norm thinks x is dull => x bores norm
e.g., Norm thinks P => interesting but }P(x) , thus is x un-interesting?
e.g., Interesting (x) => }boring (x)
e.g., Tacit: more familiar => more boring & more recent => more
familiar
I hope this gives you enough grist to move on.
My image of what you're producing is a front-end to RLL to let me build
my own conceptual definitions easily; a matching method that finds instances
of concepts in inputs; a matching method to find stored things that
correspond to coneptual descriptions; and a method to extend or rectify
conceptual defintions in light of errorful performance or new desires.
Push on!
Rick
-------
∂18 May 1981 2355-PDT RICK Plan revisions**2
To: Bill, Greiner, Wescourt, Barbara, Norm at RAND-AI, Mike
cc: rick
Folks:
I'm sending you part 1 from rand-ai.
Part 2 will come from the vax.
Rick
--------------
0<RICK.PLANNER>WORKBENCH-TODO-2..2 18-May-81 21:01:40, Edit by RICK
I really liked the plan revisions you generated. In fact, after many
hours, I haven't fully assimilated and balanced all of the suggestions.
I have some reservations however, owing to my desire to use the workbench
and to demonstrate some of the features I think are key.
Most of the proposed plan revisions were very "programmatic", i.e. they
helped specify what the people on the project should spend their time on.
These kinds of suggestions are on-target. However, I recognize now that
most of them are questionable, because we do not yet have a design in
hand for the demo system. A design would heavily constrain the programmatic
plans, more than is otherwise possible. My hope is that we can have that
design soon. I also think it can and should be more ambitious that kludge
is currently (not because kludge and its enhancements are unambitious, but
because we should be handling a richer set of replanning issues).
My primary objective is to complete this design. It should specify
what additional capabilities we believe are essential over what kludge now
provides, and it should also specify exactly how we are going to develop
these capabilities (what software, specifically, will be needed?). To do
that I think we should develop a hybrid programmatic plan that recognizes
an immediate need to "scope" the range of capabilities the demo system will
have. At the same time, we should specify our first cut at the specific
capabilities in each category. Then, in parallel, we should begin designing
the software and continuing along the research paths which support our work.
So, to do this, we need to flesh out the "demo" capabilities, in type
and minimum specifics. Then we need to design the software to go along with
those, and resume the research which is needed to pull off a good demo.
Below, I have added some "missing" goals (vis-a-vis the BHR&NS plan).
After that, I review the proposed plan revisions you generated (using
plusses and minusses to indicate my concurrence (disagreement) with the
proposed activities. After you have read this, prepare for a wednesday
discussion of the overall implied agenda. Thanks.
my goals which weren't satisfied by the proposed plan
g1. A system that I and others can use to manage project plans
g2. A system that helps enter, review & validate plan rationales
g3. A system that generates useful hardcopy (e.g., plan schedules)
g4. A system that accepts plug-in modules to support some domain
specific ramification (e.g., time and money calculations)
g5. A system that supports evolving plans and their rationales
g6. A system that accepts and exploits multiple levels of abstraction
g7. A system that answers specific (but generally interesting)
replanning questions.
g1. A system that I and others can use to manage project plans
pro> These are my biggest problems & the tool fits.
pro&con> this increases emphasis on immediately utility
infer> the system should support the exemplary plans we all
have generated, including BHR&NS's, BS's, RHR's,
& ROSIE
pro> this leads directly to probable FY82 application area
subgoal> g2 & g3 & g4 & g5 & g6
g2. A system that helps enter, review & validate plan rationales
pro> this is what the workbench is about
pro&con> emphasizes project breadth rather than depth
infer>this argues against deemphasizing rationale entry issues now
alternatives> for entering: integrate kludge with editor E
| build entry pgm
for review: integrate kludge with editor E
| build new review pgm
for validation: --what can we do here??
subgoal> specify ways for one item on entry to refer to others easily
g3. A system that generates useful hardcopy (e.g., plan schedules)
pro> very helpful & perhaps easier than general graphics
con> might be hard
example> BHR&NS's schedule at bottom of their workbench-todo revision
alternative> if plan rationales are in English & maintained by editor
they should be readable and printable simply
g4. A system that accepts plug-in modules to support some domain specific
ramification (e.g., time and money calculations)
pro> parameterized sentences & dependencies among them are important
con> this can be very hard
pro> project management has lots of good examples
pro> this is something that can be automated and can help replanning
pro> we should practice putting in hooks in ramification
alternative> create arithmetic equations between parameters &
respond to an edited sentence by ramifying the equation
pro> provides a possible source of "validation"
g5. A system that supports evolving plans and their rationales
pro> this is central to organizational replanning
pro> our plans for the project are evolving and hard to track
con> this can be hard
alternative> automate the recording of versions of items and
the linking of old and new items by an "update" pointer &
associate creator & creation time with items (this can be
done with special purpose calls from E or by a special pgm)
g6. A system that accepts and exploits multiple levels of abstraction.
pro> this helps organize the display of voluminous data
pro> this reflects the reality of many plans and rationales
con> this requires different "types" of items
con> the bicycle plan doesn't have it
pro> plans/rationales evolve often top-down (in organizations)
alternative> allow level names or numbers as part of item and
use appropriate pointer types for subordinates
g7. A system that answers specific (but generally interesting)
replanning questions.
example> Explain why one option was preferred to another
(e.g., x is more y than z)
example> What must be done BEFORE x?
example> Were there any alternatives to x that were rejected
for reasons concerning y?
∂18 May 1981 1155-PDT Keith Wescourt <WESCOURT> Revisions to CORE project plan thru end of FY 81
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
GENERAL GOALS/CONSTRAINTS
[Rick]
Consolidate and package our efforts to date. If we find the project
is not to be continued, what can we present to the AF and the world as
our accomplishments.
{
We have a responsibility to the AF.
We want to be able to coherently describe what we've done to
colleagues.
We MAY need it to help secure further support.
}
--i assume we will continue beyond this year
[Rick]
Secure support for further work.
{
We want to continue the project.
++i assume we'll all play a role in this }
[Bill, Rick]
Associate the project with a real-world planning task either internal
or external to Rand, but external to our own immediate self-interests
(it can affect us, but should be someone elses problem and
responsibility).
{
++i personally like bill's idea to look into AF basing as a possibility
--i incline also toward project management (internal) for its benefits
Such a problem will motivate us to do better work.
Such a problem will give the project credibility and visibility that will
enhance its prospects for having a real outcome and our own
careers.
}
[Rick]
Maintain the productivity and happiness of project staff
{
+the best way i know how to do this is by a coordinated design cum programatic
plan
Promote the cohesiveness and stability of the project.
Increase the likelihood that the project will generate something
worthwhile.
Satisfy the personal goals of project staff
}
GROUP ACTIVITIES
[June 15, Rick]
Articulate a motivation for what we are doing that anticipates the
questions we have had directed at us in previous briefings and
discussions. Each staff member must learn that entire motivation.
+kw: please look at the WD and see what's missing if anything.
+ when we revise it, we'll take care of it
What is the problem?
Why do we think a primarily technological solution can solve
it?
Even if we can generate a solution, why do we think we can get
anyone to use it?
{
We need to be able to determine whether our efforts are making any
progress.
We should share a common perspective on what we are doing.
Everyone should be able to brief the project to clients/visitors.
}
[?date?, Norm]
Evolve the existing Kludge system into a demo that we feel comfortable
showing to people outside Rand.
-i think you need to be considerably more constructive here
{
The demo is a vital part of our reporting requirements.
The demo is a vital part of our efforts to get continued support.
The existing demo is inadequate from many perspectives.
}
[July 1, Keith]
Expand our goal for the workbench to include it's use as a tool to
monitor and control the execution of parameterized (conditional)
plans. Develop additional motivation and determine any additional
features the Workbench might need to support such application.
{--i think for now this is off the main-line
Potential supporters of the research seem to have less trouble with
this type of use than with replanning.
Little in the way of additional system functions may be needed to support
this type of use.
}
[July 1, Barbara]
Develop a consensus about how the workbench ought to be used within
existing organizational planning situations OR how organizational
planning must be changed to accomodate use of the Workbench in order
to reap its benefits. Focus on how a big plan and rationale is going
to get entered into the system in the first place.
--i think this is too hard now: let's focus on the demo
{
It is hard for most people to imagine how this technology will be
able to work in real organizations.
If we are going to work on a real planning task, we'd better be able to
specify in detail to the organization collaborating with us how we
are going to interact with them.
The design of any further retrieval capabilities for the demo software
depends on the assumptions we can make about how much structure will
be imposed on the database at the time it is entered.
}
[July 15, Keith]
Develop a consensus about the types of queries the Workbench will be
able to support. In particular, should it directly aid decisions at
high levels of abstraction (e.g., "if I now believe X and Y, which
parts of the plan can I still use") or should it only answer questions
about the relationships between the indivdual items in the database.
++ crucial, and right on
{
Our present direction is toward a system that requires the end-user
to understand the database structure so he/she can translate
questions about how to replan into lower level questions about
the relationships between plan structures and then figure out how
the answers to those low-level questions bear on his/her problem.
The system might be easier to use if it could answer the more
high-level questions directly.
}
INDIVIDUAL ACTIVITIES AND SUB-TASKS
[July 15, Norm, Keith]
Re-write existing Kludge software to use existing tools like
Lex and YACC.
- seems the cart before the horse: let's get the questions first
{
Improve scope and efficiency of "conceptual" retrieval
Make software more easily extensible
}
[?date?]
Identify and implement features of a demo that will make it
attract the uninitiated and help convince them that a real
system will be worthwhile.
-First, what is the point of the demo?
Things we can do now, without more hardware:
[Norm] character graphics (e.g., to draw/edit plan/rationale structures)
[Keith] menu-driven querying and maybe entry of database items and
structure
[Keith, Barbara] on-line interactive tutorial
[Barbara, Keith] off-line tutorial reference manual
{
The demo must be usable, if only to allow demonstrations where
users can themselves discover the value of such software.
}
[July 15, Bill, Barbara, Norm]
Elicit and record an entirely new bicycle plan and rationale under
more controlled conditions.
-i think the project management task is better
Act as if it was the first time we were working on a problem in
this domain.
Make it longer, more complex (e.g., a multi-day trip -- norm doesn't
really have to take it).
{
After developing a consensus about how the Workbench will be used
to elicit and record rationales we need to test those ideas.
The present rationale and plan have been compromised by ad hoc,
post hoc additions required to make our initial demo do any
interesting.
We need a plan that has more contingencies/alternatives in it if the
demo is to seem non-trivial.
-+ i'm not sure I follow this, elaborate please
}
[Aug 1, Bill, Rick, Barbara]
Select a real-world planning problem and have 2 or more of the the
project staff familiarize themselves with the domain to the extent
that they can serve as articulators for planners in that domain.
Generate an a priori conceptual hierarchy (e.g., a la LEX, for the
domain)
+ perhaps bill's current suggestion will pan out
{
Demonstrate to a would be client that we are ready to move to a
real domain.
Get a feeling for how much conceptual structure for a plan and
rationale can be defined prior to planning and thus be available
to structure the database when a plan is being developed.
Be ready to start work in the domain as soon as we secure support
for the next FY
}
-------
∂8 May 1981 1320-PDT Keith Wescourt <WESCOURT> PROJECT PLAN HW
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
0<WESCOURT.PLANNER>PROJECT-PLAN..5 8-May-81 13:17:32, Edit by WESCOURT
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
KW's Notation:
/kw == kw's rationale statements
{kw: ....} == kw's questions and suggested revisions
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
+ i found nearly all of your insertions throughout here illuminating.
you can see how much more is needed to "justify" this version of the plan
/kw searching for raw strings is inadequate
/kw conceptual structure must be accessible to encoder & retriever
> Easy conceptual extension
/kw encoder & retriever will develop new useful conceptual distinctions
as the workbench is used
/kw it is impractical for users to manually attach new conceptual
knowledge to existing items
> Good plan rationale entry, especially proof construction
/kw users cannot be trusted to enter consistent structures without
without aiding
> Some graphic display
/kw we believe that graphics are necessary to make stored rationales
understandable
> Some graphic editing
/kw given graphic display, graphic editing is a natural medium for
changing stored structures
> Reasonably complex problem
/kw outsiders won't be interested with successes on toy problems
/kw we want to work on something meaningful to us
/kw a complex problem is needed for us to discover the important
issues in building and using a workbench
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
/kw origin of plan contents and knowledge of plan evolution are
important for understanding and evaluating it-- they supply
additional, implicit rationale
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
/kw each person has some different skills and interests
/kw the rand environment stresses individual accountability
- i think that's wrong: i look for ways to divide & conquer
and to motivate individual excellence
/kw we think we will be more productive by subdividing responsibility
> Each specifies what he/she wants to produce
/kw this will make division of responsibility more meaningful
/kw we think we should be able to pursue our own interests within
the context of the project
> Collaboration to integrate designs
/kw given division of responsibility and individual choice of direction,
negotiation between individuals is essential to build a working
system
> A usable tool
> Viable, friendly, moderate speed and size
++ /kw the system must make a good impression on outsiders who use it
++ /kw we won't enjoy working with a slow, clumsy-to-use system
> A good self-contained demo & tutorial
/kw we don't want to be burdened with personally acquainting people
with the system
/kw people are impressed by systems that they can understand and learn
to use without hand-holding
/kw a system is not complete without documentation
> Complete our Kludge experiments by June 1
> Rerun the experiment
+ /kw we don't feel we learned enough from the first experiment
+ /kw the software wasn't adequate for the first experiment
? /kw we think we can do better the second time around
> Run the experiment on ourselves
+ /kw we all need to know how to use the software well
+ /kw we all need to be able to appreciate the system from the
users' point of view
+ /kw we all need to understand the cognitive/emotional aspects of
trying to do disciplined replanning.
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
+ /kw we are shooting for a Oct 1 demonstration
/kw we already have a set of objectives we know we cannot fully
satisfy by Oct 1
> Define a useful example
/kw we think that we cannot yet create a problem-independent
workbench so we need have the application clearly in mind as
we develop this prototype
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
/kw preprocessing will make retrieval faster at run-time
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
/kw we can't support arbitrary questions
--still need to:/kw we think we have identified the most useful/frequent types
of questions
> Allow a flexible language for describing patterns of both
conceptual and string matching
/kw the conceptual hierarchy will probably not be sufficient by
itself
/kw the user will be able to access the database and identify
raw strings useful for search
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches {kw: what does this mean?}
/kw we should support sysntactic as well as semantic variations
> Easy conceptual extension
{kw: this seems like it will be tricky with preprocessing}
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
{kw: How about using interactive menus driven by "planning grammars"}
- what benefits do you see? be specific on the type of entry.
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
/kw it is tedious to manually replicate the same structure for
several different plan steps
> Need implicit satisfaction of constraints by all actions
{kw: I'm not sure what this means}
+ subplans inherit constraints from about & presumably
satisfy them
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
+ /kw representation of some things by exclusion rather than inclusion
has certain advantages
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
/kw we think people generally want to limit or at least control the
level of detail they must see at any time
> Varying attributes/dates/designations of items => varying symbols
/kw people need powerful simple ways of distinguishing classes of
information
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
/kw emergency replanning is a very motivating problem for most people
at Rand
/kw we could all feel like we were contributing to society
++ yep, this would be a good one if we could find one & rationalize it
/kw emergency (re)planners need and WANT help now
/kw emergency planning organizations seem to lack some features
we feel may reduce the effectiveness of the workbench for
other organizations (e.g., the tendency to hide reasons from
others)
> A military one
/kw there is a lot of military expertise at rand
/kw the DoD is paying for this research right now
/kw the military needs planning help
/kw ~ it's hard to get access to military data for real,
interesting problems
/kw ~ most of us would rather not wopπpon classified problems
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
++this sounds generally good to me
keith: plan evolution (retro & pro-active) & question-answering
{kw: tutorial, too. I see the order/priority of my tasks to
be question-answering; paln evolution; tutorial}
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
{kw: >> menus}
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
{kw: >> menus}
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
-------
∂15 May 1981 1331-PDT BILL revised plan with task assignments
To: rick
cc: barbara, norm at RAND-AI, wescourt
Bill's recommendation for overall plan, including his work assignments.
KEY ++ i found this to be pretty readable
g> goal
t> task
p> pro rationale
c> con rationale
s> status, comment
m> milestone
a> allocation, assignment
------------------------------------------------------------------------------
g> Lay groundwork for FY82 workbench research.
t> Report research results through FY81.
+ yes worth doing
m> Begin 31 Aug.
m> Complete 30 Sep.
p> Standard procedure.
c> Not in original plan.
p> Bill would like to help with this.
t> Analyze future workbench research alternatives.
- too late to help; always going on
m> Begin 31 Aug.
m> Complete 30 Sep.
p> Will help Rand and possible sponsors decide whether and in what
manner to support further workbench research.
c> Uses resources that would otherwise be available for demonstration.
c> Not in original plan.
p> Bill would like to help with this.
t> Generate and screen research alternatives.
t> Estimate impacts of research alternatives.
t> Evaluate research alternatives.
t> Demonstrate current capability.
--AI isn't necessary:
p> We want to demonstrate that AI techniques can help planners perform
some selected (re)planning function(s) better in some
specified respects than is presently done.
p> A necessary condition for further funding.
c> Not same wording as original goals.
--what do you think of bhr's existing demos?
m> Begin 18 May.
m> Complete 31 May.
t> Develop plan/rationale as vehicle for demonstration.
p> Necessary for any demonstration.
++this seems like a good task but I need to know more about it
p> Bill would like to work on this if the selected source were
a policy planning study, such as the Strategic Air Base study.
t> Develop plan/rationale entry capability.
++ i think this is very important
t> Identify application planning area for demonstration.
s> Possibly Strategic Air Base study viewed as plan.
p> Well known, classic Rand work; puts our research in
good company.
p> Basing is a current interest of Air Force.
p> R-266 presents relatively simple alternative unclassified
plans together with rich rationale.
+- replanning yes: but will the workbench help? how?
p> Demonstration should feature simple but highly
rationalized plan.
p> Examining R-266 as a source for base replanning has appeal;
analogous to Charles Wolf's recent examination of Hitch &
McKean's classic with respect to current situation.
p> Original participants still at Rand include Hoffman, Digby,
Hogg, Dadant, Augenstein, and DeHaven.
p> Forty page summary provides ample plan/rationale for our
demonstration; basic document of 380 pages provides greater
depth for specific points needing clarification.
p> Could be entered into database relatively fast.
- i don't see why you believe this
p> Bill would like to work on this.
t> Develop concepts for structuring rationale.
t> Conduct experiments to aid concept development.
- please be more specific
t> Develop plan/rationale processing software.
t> Design software.
s> Software should be usable by all of us.
s> Software should be usable by others under guidance of a
project member.
s> Software should support replanning in one or two selected
domains.
+++++ t> Specify (re)planning function(s) the demonstration
software will aid.
p> Functions identified in WD-963, slightly modified, include
++TOUCHE! DOCUMENT
Record
Update
COMPREHEND
Review
Brief
Interrogate
VALIDATE
Verify
Justify
ANALYZE
Detect
Assess
Compare
?? p> We can't do all the functions (review, brief, interrogate,
verify, justify, etc.) in the demonstration.
+Which? p> We should demonstrate feasible functions that most clearly
suggest the value of a computer aid to replanning.
p> Three clearly useful functions are better than more
less convincingly useful functions in demonstration.
t> Specify AI techniques to be embodied in demonstration software.
---- Only if very desirable
t> Determine hardware suite.
t> Determine mix of existing and new software to be utilized.
t> Determine mix of software for plan entry and modification.
s> Possibly unix, english parser, yacc, lex, or menus.
t> Determine mix of software for data base.
s> Possibly unix, berkeley's rdb system (isis).
t> Determine mix of software for conceptual encoding.
s> Possibly lisp, ellie/yacc.
t> Determine mix of software for query.
s> Possibly lisp, ellie/yacc, menus.
t> Determine mix of software for search.
s> Possibly rll, lisp, grep, isis.
t> Specify relationships between software and demonstration.
t> Code software.
t> Test software.
t> Develop display/graphics capability.
p> Graphics in itself has good selling power.
t> Determine mix of software for display.
s> Possibly small talk, megatek.
s> Possibly "flowcharting" software.
t> Determine mix of software for hardcopy generation.
r> We need hardcopy of session traces.
s> Possibly unix, laser, "flowcharting" software.
t> Develop meta-planning software.
m> Begin 1 Jun.
m> Complete 21 Aug.
p> There are possibly big benefits from meta-planning heuristics;
we should demonstrate some interest/capability in this area of AI.
s> Possibly Rosie software that would interact with planner,
suggesting to him or her how to use the mainline plan/rationale
processing software.
p> Rosie would facilitate fast development.
p> Rosie would provide friendly, transparent interface.
c> Would require using the 20.
p> Bill would like to work on this.
t> Design software.
-- this is possible, but you're statement of goals & tactic is vague;
also i feel this is cart before the horse, current task is the workbench
s> Possibly would use user description of current problem in
terms of menu-offered functions, modes, and roles to recommend
ways to use the mainline software.
--Huh? s> Possibly would have some capability to learn particular user's
replanning style and heuristics to suit that style.
t> Specify (re)planning function(s) the demonstration
software will aid.
p> Functions identified in WD-963, slightly modified, include
DOCUMENT
Record
Update
COMPREHEND
Review
Brief
Interrogate
VALIDATE
Verify
Justify
ANALYZE
Detect
Assess
Compare
--please tell me what you think replanning needs if you know.
t> Specify (re)planning mode(s) demonstration software will aid.
p> Planners faced with the same task differ in their mode of/
approach to (re)planning.
p> Mode specification helps structure (re)planning.
p> Observers of the demonstration will prefer different modes.
p> Modes imply heuristics, some of which we can model.
p> Some modal heuristics are too difficult to model in the
time available; hence we need to specify those we can do.
p> Software embodying modal hueristics could help (re)planners.
p> Bill would like to model modal heuristics.
p> Modes identified in Faludi's text on planning theory include
-- i don't see what you could do in this area? do you?
IMPOSING PATTERNS ON INFORMATION
Routinization
Sequential decisionmaking
Mixed scanning
CONTROLLED SUSPENSION OF RATIONAL PLANNING
Satisficing
A priori decisionmaking
Random decisionmaking
CREATIVE (RE)PLANNING
Convergent thinking
Divergent thinking
BALANCE
Open-mindedness
Will power
t> Code software.
t> Test software.
t> Develop demonstration tutorial.
p> Aids observers and effectiveness of demonstration.
p> Helps assure integrity of all parts of demonstration; as
disconnects will become apparent in tutorial development.
t> Specify system interfaces.
t> Specify the type of planners/planning software will demonstrate
being aided.
++ t> Specify the respects in which use of demonstration software will
be better than (re)planning without it.
t> Specify relationships between software and demonstration.
p> Whatever the software alone doesn't do to achieve the first
goal must be done by the demonstration.
t> Identify likely observers of demonstration.
>p Might be possible and desirable to tailor demonstration to
observers.
t> Stage the demonstration.
t> Design demonstration.
t> Prepare demonstration materials.
t> Make administrative arrangements for demonstration.
-------
∂TO Rick@Rand-Ai 15:38 20-May
Verbose Message
0) Overview of this message:
1) Meeting with Norm
2) Things I think I may understand, sorta
3) Major outstanding questions
4) Comments on SRI's SIPE paper
5) Ptr to Relations among rationale
6) Misc comments/problems (Rand-Unix)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
1) Whew - you didn't warn me about Norm's AntI-AI feelings.
Anyway, I learned a bit about UNIX, and attempted to describe
the basic idea of a frame based representation system.
I was then rather hazy about the nature and scope of my assignment;
and so could not have described it adequately to Norm.
That conversation did serve to expose
a wealth of possibly inaccurate perceptions of my role in
the task, which I hope your response (to part 3 in particular)
will help to clear up.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
2) As I understand my task, one part involves enumerating standard relations
which can be used to define new concepts.
I list below some obvious connective which relate pairs (n-tuples) of concepts
with one another. Note the arguments to these relations maybe
either "noun/adjective-like" (eg Naomi, Hilly) or "verb-like", as
in Like. I haven't resolved whether there should be seperate relations
for these cases.
(The vagueness you'll find in the descriptions mirrors my great uncertainty
about these connectors. I'll think harder about these, if you confirm that
I'm at least sorta on the right path.)
Synonym -
(Synonym x y) means x and y denote the same thing, in this context.
Hence, when scanning for y's, one should look as well for x's,
and vice versa.
Ex: (Synonym Wife Naomi) - in this example.
(Synonym Like Love) [taking liberties with English for this example]
Specialization -
(Specialization x y) means x denotes a specialization of y.
Hence, when scaning for x's, one should seriously consider any y's found;
as some y's will, in fact, be x's as well.
On the flip side, any x is AKO y, so use any x's found when trying
to find instances of y.
Ex: (Specialization GroceryStore Store)
(Specialization Like Affection)
[Yes, this may be slur of Element and Subset, and who knows what else.
For this application, though, I couldn't find any case where this
distinction ever made a difference.]
Generalization -
(Generalization x y) - this is handled as (Specialization y x).
Antonym -
(Antonym x y) means both x and y are the same "type" of thing,
but should be regarded as exclusive.
Hence finding x automatically means not y is not the case, and
vice versa.
Ex: (Antonym Flat Hilly)
(Antonym Like Hate)
Exclusive -
(Exclusive z x1 x2 ... xN) means all xi are specializations of z,
but are exclusive. This is clearly related to Antonym, but I'm
not quite sure.
Ex: (Exclusive Store GroceryStore HardwareStore)
(Exclusive BasicTastes Bitter Sweet Acid Sour)
-----
Note this isn't quite enough to handle those cases where
the arguments are "verb-like". Here we have to consider the order of
THEIR arguments, which may differ. Eg
(Synonym INTERESTs LIKEs)
would seem to imply
x LIKEs y <=> x INTERESTs y,
which is wrong.
The relation is really
Norm LIKEs roads <=> roads INTEREST Norm.
Perhaps we should use a slew of specializations of this Synonym relation,
to deal with various rearrangements of the arguments.
Another possibility, which I shy away from, is to define these interrelations
in predicate calculus -- eg
(All (x y) (EQUIVALENT (Match (x LIKEs y)) (Match (y INTERESTs x)))),
and shunk the above Synonym, Antonym, ... stuff above -- or rather, use it
only as a short hand, which expands into the form the inferencer "really"
uses, shown above.
This second possibility seems rather confusing to me; and may open a Pandora's
Box of further complications -- eg determining the sort of the variables
x and y above, or handling the modal operators which would eventually crop up.
Comments?
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
3) Now for things I really don't understand:
Just what do you want RLL to be able to do with such links.
Eg spse the systen knows (Antonym Likes Hates).
What sorts of inferences should RLL perform?
If the user now asks "What does Norm like?", what query should be fed to
Kludge (or its descendent)?
(i) For all rationales, r, of the form (Norm likes x), return
"Norm likes x" .
(ii) For all rationales, r, of the form (Norm hates x), return
"Norm does NOT like x" .
(iii) For all rationales, r, of the form (Norm <a> x) where
<a> is either Likes or Hates,
return each r for user inspection.
I had thought (i) and (ii) were expected for this task; Norm seemed to feel
(iii) is the desired answer.
Now imagine a harder challenge --
Design a trip involving more things which Norm likes to do.
Should RLL now know enough to propose an escape involving more of those x
such that (Norm likes x), and fewer y such that (Norm hates y)?
Again Norm shunked this is not-possible or even desirable; prefering
simply an enumeration like (iii) above; leaving the rest to the user.
---
This question could be resolved with a few I/O pairs --
First, what sort of inputs which you would like the user to be able to type
in, to link together appropriate concepts.
In that context, what sorts of questions should this RLL preprocessor expect
to see; and what DB queries should it generate (for Kludge) in response?
----
On a related theme, what other sorts of things should RLL know about?
(Especially assuming the front end is NOT predicate calculus,
[the suggestion I advised strongly against above],)
should it be able to handle quantifiers like SOME, ANY, ...
and quantifier-like things, eg MORE, LESS.
[This is necessary to deduce that "Less Boring" is a SYNONYM for
"More Exciting", given that (Antonym Boring Exciting).]
How about declaring that LongerThan is Transitive. This will allow RLL
to reason that Trip1 will be longer than Trip3, from the facts,
(LongerThan Trip1 Trip2) and (LongerThan Trip2 Trip3), stored in the data base.
For this task does RLL have to know enough to declare some new connection
invalid -- eg that it contradicts another declaration (in the sense
that (Synonym x y) and (Antonym x y) are incompatible), or that it violates
some type constraint -- should RLL be able to state that only animate things
can ENJOY some activity?
Feel free to answer any other question along these lines -- of what this
preprocessor should be able to do...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
4) I sent along the proto-IJCAI-candidate paper Dave Wilkins & Ann Robinson wrote.
Most of that project seems orthogonal to this project.
It is dealing primarily with interactive planning,
in the earlier Sacerdoti et al sense,
as opposed to providing easy means for subsequent replanning.
Its many built-in parts actually seemed rather similar to Wilensky's
current stuff; but that's neither here nor there.
The paper's most relevant part was its brief description of SIPE's
graphics interface, pp 12 - 14, ish.
Final note - feel free to read the paper, but NOT to quote it without permission.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
5) Understanding what sorts of links should join rationale and plan steps
with one other seems critical to my task.
Is Barbara "in charge" of this research area?
I concocted some relations which seem deserving; shall I send
them to Barbara for revision/demolition?..
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
6) What is the status of Rand-Unix? I've been totally unable to TELNET there.
(I always find myself REFUSEd.) Is there some trick?
Also, what is its site number? (IE To connect there from the local tip,
I type @L ?, for some number ?. Any idea what the number is?)
Anyway, is there someway I can find if I've any mail there; and if so,
get it forwarded to, say, GREINER@RAND-AI? Thanks.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Sorry about the ill-structuredness of the questions in this message;
and thanks, in advance, for your anticipated-to-be-illuminating response.
Russ
∂21-May-81 0802 RICK at RAND-AI reply to your msg
To: rdg at SU-AI
cc: rick at RAND-AI
Russ: My comments are at asterisks in your original. - Rick
---------------
Mail-From: SU-AI rcvd at 20-May-81 1539-PDT
Date: 20 May 1981 1538-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Verbose Message
To: rick at RAND-AI
0) Overview of this message:
1) Meeting with Norm
2) Things I think I may understand, sorta
3) Major outstanding questions
4) Comments on SRI's SIPE paper
5) Ptr to Relations among rationale
6) Misc comments/problems (Rand-Unix)
1) Whew - you didn't warn me about Norm's AntI-AI feelings.
**If i thought you needed protection, I'd have given it to you.
Anyway, I learned a bit about UNIX, and attempted to describe
the basic idea of a frame based representation system.
I was then rather hazy about the nature and scope of my assignment;
and so could not have described it adequately to Norm.
That conversation did serve to expose
a wealth of possibly inaccurate perceptions of my role in
the task, which I hope your response (to part 3 in particular)
**Your role is still ill-defined. Don't be alarmed by that.
will help to clear up.
2) As I understand my task, one part involves enumerating standard relations
which can be used to define new concepts.
I list below some obvious connective which relate pairs (n-tuples) of concepts
with one another. Note the arguments to these relations maybe
either "noun/adjective-like" (eg Naomi, Hilly) or "verb-like", as
in Like. I haven't resolved whether there should be seperate relations
for these cases.
(The vagueness you'll find in the descriptions mirrors my great uncertainty
about these connectors. I'll think harder about these, if you confirm that
**From what I see below, you're on the right path. That is supposed to be a
**path that leads to a capability to find stuff in the rationale which
**is related to other stuff (or just to words in English) by query-specified
** relationships. (Ie., can we do "knowledge retrieval" without completely
** general natural language understanding. I think yes. I suspect the
**capability required will combine three things: (1) a syntactically
**constraind syntax for english input; (2) a broad collection of domain-
**specific concepts (e.g., words, phrases); and (3) conceptual relationships
** like Synonymous(x does not verb y, x does (antonym verb) y)
**Thus, in what follows you are on the right track wrt (3), which is the area
**I asked you to focus on first. But you should comprehend (1-3) and tell
** me if i'm wrong in the overall approach.
I'm at least sorta on the right path.)
Synonym -
(Synonym x y) means x and y denote the same thing, in this context.
Hence, when scanning for y's, one should look as well for x's,
and vice versa.
Ex: (Synonym Wife Naomi) - in this example.
(Synonym Like Love) [taking liberties with English for this example]
Specialization -
(Specialization x y) means x denotes a specialization of y.
Hence, when scaning for x's, one should seriously consider any y's found;
as some y's will, in fact, be x's as well.
On the flip side, any x is AKO y, so use any x's found when trying
to find instances of y.
Ex: (Specialization GroceryStore Store)
(Specialization Like Affection)
[Yes, this may be slur of Element and Subset, and who knows what else.
For this application, though, I couldn't find any case where this
distinction ever made a difference.]
Generalization -
(Generalization x y) - this is handled as (Specialization y x).
Antonym -
(Antonym x y) means both x and y are the same "type" of thing,
but should be regarded as exclusive.
Hence finding x automatically means not y is not the case, and
vice versa.
Ex: (Antonym Flat Hilly)
(Antonym Like Hate)
Exclusive -
(Exclusive z x1 x2 ... xN) means all xi are specializations of z,
but are exclusive. This is clearly related to Antonym, but I'm
not quite sure.
Ex: (Exclusive Store GroceryStore HardwareStore)
(Exclusive BasicTastes Bitter Sweet Acid Sour)
-----
Note this isn't quite enough to handle those cases where
the arguments are "verb-like". Here we have to consider the order of
THEIR arguments, which may differ. Eg
(Synonym INTERESTs LIKEs)
would seem to imply
x LIKEs y <=> x INTERESTs y,
which is wrong.
The relation is really
Norm LIKEs roads <=> roads INTEREST Norm.
Perhaps we should use a slew of specializations of this Synonym relation,
to deal with various rearrangements of the arguments.
Another possibility, which I shy away from, is to define these interrelations
in predicate calculus -- eg
(All (x y) (EQUIVALENT (Match (x LIKEs y)) (Match (y INTERESTs x)))),
**This is just hwa the matcher needs. The best defining form might be a macro
**which combines this with the Synonym, etc. simpler forms.
and shunk the above Synonym, Antonym, ... stuff above -- or rather, use it
only as a short hand**Right: isn't it all just shorthand (ie,symbolic equivalents?)
, which expands into the form the inferencer "really"
uses, shown above.
This second possibility seems rather confusing to me; and may open a Pandora's
Box of further complications -- eg determining the sort of the variables
x and y above, or handling the modal operators which would eventually crop up.
Comments? (**Can't be avoided as far as I see. Push on!)
3) Now for things I really don't understand:
Just what do you want RLL to be able to do with such links.
**In general, I want RLL to convert a query into a regular expression for
**searching the data base: you tell me what patterns will match the query.
**Different query types will affeect how you translate a query into the
**eventual search pattern. Ultimately, not now, I want the system to
**grow into an intelligent formulator of patterns for retrieval search, one
** that will suggest its "best" ideas first, and then follow-up with alternat-
**ives if the first doesn't pan out.
Eg spse the systen knows (Antonym Likes Hates).
What sorts of inferences should RLL perform?
If the user now asks "What does Norm like?", what query should be fed to
Kludge (or its descendent)?
(i) For all rationales, r, of the form (Norm likes x), return
"Norm likes x" .
(ii) For all rationales, r, of the form (Norm hates x), return
"Norm does NOT like x" .
(iii) For all rationales, r, of the form (Norm <a> x) where
<a> is either Likes or Hates,
return each r for user inspection.
I had thought (i) and (ii) were expected for this task; Norm seemed to feel
(iii) is the desired answer.**Obviously, you're both right. It depends of
what type of Q it is. One "type" corresponds to each of the possible answers.
**E.g., (1) Scan the rationale for "Norm likes x".
(2) Scan the rationale for ~"Norm likes x"
(3) Scan the rationale for items about "Norm likes x"
Now imagine a harder challenge --
Design a trip involving more things which Norm likes to do.
Should RLL now know enough to propose an escape involving more of those x
such that (Norm likes x), and fewer y such that (Norm hates y)?
**Not by itself (at first). But if I want to say that that's the meaning of
** the concept ("Better for norm"), I'd like to be able to extend the concept
** base in an easy way so the answer to "What's better for norm?" will find
** just the right things and prhaps help me understand whichitems matched
**which part of the branched conceptual definition.
Again Norm shunked this is not-possible or even desirable; prefering
simply an enumeration like (iii) above; leaving the rest to the user.
**Norm doesn't want to try to solve problems he doesn't know how to. You
**do, and so do I. So you need higher aspirations. But don't expect
**Norm (or anyone else) to think you wll succeed. Even I think you might
**fail because it's hard: you must specify a currently unslved problem
**well, and then solve it well.
---
This question could be resolved with a few I/O pairs --
First, what sort of inputs which you would like the user to be able to type
in, to link together appropriate concepts.
**We are about to generate lots of "replanning specific questions" which should
help give you illustrations. Make up your own, e.g.,
Replan to make the trip shorter=>need to find those things that determine
trip length & alternatives to them which might inversely affect length ->
Query: Items about TripDuration -> Items about TripPartLengths & Items about
TripPartSpeeds & AlternativesToTripParts(x) & LengthsOf(x) & SpeedsOn(x) ->
"Kludge: find all the items where "x is a part of the trip" or "the trip
includes x", feed each x back to me" & (for all x received) "Kludge:
final all the items whre "y is the length of x" or "x is y DistanceUnits""...
**Note, BIG QUESTION: Obviously, I'd like to have the ability to just say
to my DB, "Find all items(x,y) such that x is a trippart and y is the length
of x". But I don't know how to do that in one system we can build today,
given the relatively free and breezy form of plan items. So, I'm trying to
find a hybrid of "logical inference" in RLL and fast string matching in Unix.
Do you think the whole system could be done in RLL, even with the long
and verbose string matching? (Realizing that we expect 10**4 or more items?)
It doesn't seem likely. So we need to continue conceptualizing how some of
the smarts about what to look for, in what order, can be done in RLL. As my
preceding example suggests, it might be a dialog of sequential interactions
between RLL And KLUDGE just to answer prt of a complex question. The
advantage to doing this in RLL should be that we could modify both the
concept definitions and the interactive dialog definitin required to answer
complex queries. I don't know exactly waht it will take at this time.
**end
In that context, what sorts of questions should this RLL preprocessor expect
to see; and what DB queries should it generate (for Kludge) in response?
----
On a related theme, what other sorts of things should RLL know about?
(Especially assuming the front end is NOT predicate calculus,
[the suggestion I advised strongly against above],)
should it be able to handle quantifiers like SOME, ANY, ...
and quantifier-like things, eg MORE, LESS.**YES**
[This is necessary to deduce that "Less Boring" is a SYNONYM for
"More Exciting", given that (Antonym Boring Exciting).]
How about declaring that LongerThan is Transitive. This will allow RLL
to reason that Trip1 will be longer than Trip3, from the facts,
(LongerThan Trip1 Trip2) and (LongerThan Trip2 Trip3), stored in the data base.
For this task does RLL have to know enough to declare some new connection
invalid -- eg that it contradicts another declaration (in the sense
that (Synonym x y) and (Antonym x y) are incompatible), or that it violates
some type constraint -- should RLL be able to state that only animate things
can ENJOY some activity?**Nice, but not essential.
Feel free to answer any other question along these lines -- of what this
preprocessor should be able to do...
** Iwant to convey to you a sense of what the problem is in designing a
"real intelligent system". The basic idea is that all intelligent systems
have high-payoff, high-technology mechanisms of limited genral utility and
also a lrge number of low-payoff, low-technology mechanisms of more general
utility. Humans are a great example: we often resort to slow, tedious
manual and even exhaustive methods to solve problems for which we can't
simply solve by our high-tech methods. Our planners workbench will
necessarily be much like this. Your use of the word "preprocessor" is both
accurate and misleading. I want you to build in RLL a highly-intelligent
system that helps us find useful information in the ratinale database.
This mechanism that you build must be domain independent and easily extended
in a mature domain application. It has to guide us in choosing how we
apply our expensive, low-tech methods, such as string searching and
following inter-item pointers through a large file system. Those are the
slow parts (inherently so). By comparison, a little thinking by RLL might
be worth a lot. Can you show me how?
4) I sent along the proto-IJCAI-candidate paper Dave Wilkins & Ann Robinson wrote.
Most of that project seems orthogonal to this project.
It is dealing primarily with interactive planning,
in the earlier Sacerdoti et al sense,
as opposed to providing easy means for subsequent replanning.
Its many built-in parts actually seemed rather similar to Wilensky's
current stuff; but that's neither here nor there.
The paper's most relevant part was its brief description of SIPE's
graphics interface, pp 12 - 14, ish.
Final note - feel free to read the paper, but NOT to quote it without permission.
**ok, thanks
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
5) Understanding what sorts of links should join rationale and plan steps
with one other seems critical to my task.
Is Barbara "in charge" of this research area?
**Yes, she's currently in charge, but that means you should interact withher,
not assume she has it all worked out and will dictate the truth.
I concocted some relations which seem deserving; shall I send
them to Barbara for revision/demolition?..
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
6) What is the status of Rand-Unix? I've been totally unable to TELNET there.
(I always find myself REFUSEd.) Is there some trick?
Also, what is its site number? (IE To connect there from the local tip,
I type @L ?, for some number ?. Any idea what the number is?)
Anyway, is there someway I can find if I've any mail there; and if so,
get it forwarded to, say, GREINER@RAND-AI? Thanks.
**I have no idea why you're having trouble. Please call Keith or Doris
McClure to find out what's the problem.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Sorry about the ill-structuredness of the questions in this message;
**No apology necessary. You're grappling with a tough, mushy problem.
and thanks, in advance, for your anticipated-to-be-illuminating response.
Russ
---------------
-------
∂To BARBARA@Rand-Ai 17:08 21-May
Relns connecting Rationale & PlanSteps
At the meeting last week I objected that there were a host of
distinct relations which may connect a rationale with its "underlings",
and promised to attempt to enumerate a few of them.
I soon realized there are four categories of relations,
depending on the "domain" and the "range" of the link --
as either may be either a step of a plan or a rationale.
For notation I will assume the link, of type LinkType, connects
from HEAD to UNDERLING.
Note: I never was clear in what way a plan step
is different from a rationale. Indeed, Norm gave me the impression they
were indistinquishable, at least to his programs. In the descriptions which
follow I am assuming a plan step actually corresponds to some doable action(s)
which might take place in the "real" world; whereas a rationale is a non-temporal
fact which is assumed true in the world.
(I used scare quotes above in case we later consider meta-plan, in which case
this real world would include our thoughts as well...)
[Or do you hold the view that each Plan step be considered more like Goal?]
You'll no doubt notice a frame-like notation creeping into the examples below --
looks like I am a victim of my breeding after all. I did try to think of some
other form, but none seemed as natural and obvious...
*-*-*-*-*-*-*
PlanStep - PlanStep
[In many cases, especially those denoted with a leading "*",
there might really be some rationale implicit in
these links, which indicate why the plan steps are so joined.
In such cases, just assume these connections are simply shorthand
notations for that more elaborate connectin...]
SubPlans: To achieve the large plan HEAD one must perform, (in any order,)
each of the SubPlans, UNDERLING.
[Note there is an implicit CONJUNCTION around the members of SubPlans.]
Example -
CleanUp-Room
SubPlans: ({Make Bed}, {PickUp Clothes} ...)
SuperPlan: This is the inverse of SubPlans.
SpecializePlan: The UNDERLING is a refinement of HEAD. Example -
Norm goes to a Store.
SpecializePlan: Norm goes to a Grocery Store.
SpecializePlan: Norm goes to Draegers.
-- Note SubPlans is NOT the same as SpecializePlan.
It is true, however, that one can view any SpecializePlan as
a SubPlan; but not vice versa.
GeneralizePlan: This is the inverse of SpecializePlan.
NotSubPlan: This connects a planstep to each other planstep which are
not its subplans. It would be explicitly (ie physically) indicated
only where there might be some question as to UNDERLING's connection
with HEAD.
* DoBefore: Lists the subplans which should be done before HEAD.
Example -
Paint the ladder.
DoBefore: ( {Paint the ceiling}, {Paint the chandalier} >
* DoAfter: Inverse of DoBefore.
OrderedSubPlans: Perform each of the UNDERLINGs in order.
[This is a short-hand for the appropriate SubPlans link, and a DoBefore
connecting each member of that list with its respective
succeeding member.]
* Incompatible: HEAD and UNDERLING cannot both be performed. (Possible neither
will be executed.) (Note Incompatible is its own inverse.) Example -
Bike to work.
Incompatible: Drive (a car) to work.
* CoOccuring: Whenever HEAD happens, UNDERLING must be performed as well.
(Note CoOccuring is NOT its own inverse.) Example -
Shoot arrow into air.
CoOccuring: Arrow falls to ground.
[This is a bad example, as they are connected by a stronger causality
connection... See below.]
* Causes: HEAD caused UNDERLING to happen. Example -
Turn on water.
Causes: Water to flow out of spigot.
* Effect: Inverse of Causes.
-- The next set of links are special cases of SubPlans -- they each point
from some action, HEAD, to one or more actions which, if performed
in some way, would achieve HEAD. Many use "runtime" information.
That is, at "compiletime", when this plan was generated,
some information necessary to make a critical decision was missing.
ConditionalSubPlan: Perform the subplan, UNDERLING, iff the associated test
returns true. Example -
Norm goes outside.
ConditionalSubPlan: < {if raining} {Bring an umbrella} >
[test /\] [plan step /\]
-- Note this could be expanded to be like an If-Then, or even a general LISPy
COND. (Other bells-and-whistles include SELECTQ-like subplans, ...)
RepeatUntil: This is iteration, where the termination will be determined
based on some "runtime" test.
See all possible sites.
RepeatUntil: < {out of time?}, {See a site} >
[test /\] [Plan step/\]
[I feel really funny about this connection -- still it does seem
natural. Perhaps it should be created by using the ConditinalSubPlan
and a more primitive LOOP subplan. Who knows?]
*-*-*-*-*-*-*
PlanStep-Rationale
RationalePro: Gives reasons for this planstep. Example -
Go home at 9PM on Mondays.
RationalePro: I want to be home at 9PM on Mondays.
RationaleCon: Gives reasons agains this planstep. Example -
Go home at 9PM on Mondays.
RationaleCon: I cannot do computer work at home.
-- The next link points from a step in a plan to a <something>.
Having adopted the view that anything which is not a planstep
is a rationale, it is included in this PlanStep->Rationale category.
Comments: This points from a plan step to a statement which may, somehow,
be later seen to be relevant.
It may be a question -
Go home at 9PM on Mondays.
Comments: What if I've a lot of extra work to do?
or a meta statement -
Go home at 9PM on Mondays.
Comments: If I'm not sure whether to follow this or not,
then don't.
or just random (at least in appearance) -
Go home at 9PM on Mondays.
Comments: If Silverman goes from CBS to NBC, reconsider this command.
[yes, yes, yes -- there really was a long chain of derivation
which might have lead to this, but ...]
*-*-*-*-*-*-*
Rationale-Rationale
Supports: Gives reasons for this rationale. (Note this is like
RationalePro.) Example -
I want to be home at 9PM on Mondays.
Supports: < {I can watch TV at home (and not from work).}
{M*A*S*H is on TV at 9PM Mondays.} >
Opposes: Gives reasons against this rationale. Example -
I can do computer work at home.
Opposes: < {I have no terminal at home.} and
{I need a terminal to do computer work.} >
Specialization: Like SpecializePlan. Example -
I want to be home in the evening.
Specialization: I want to be home at 9PM.
Generalization: Inverse of Specialize.
*-*-*-*-*-*-*
Rationale-PlanStep
RatProOf: [Inverse of RationalePro]
RatConOf: [Inverse of RationaleCon]
*****
The above list is by no means complete; but do somewhat correspond to
my intuitions on what sorts of things people will want to say.
I'd be interested in comments -- especially if it turns out I'm
totally wrong about some assumption which led to these.
Still to do
I would feel a sense of closure if I felt we had a sufficient class of
connective to "map" all of the connectives
found in predicate calculus - AND OR NOT EVERY EXISTS.
Some of these are already handled --
eg AND was handled by the SubPlan, in all of its flavors.
NotSubPlan is like NOT, and ConditionalSubPlan can be used to
awkwardly simulate OR.
The others (eg quantifiers) may or may not even be relevant...
Thoughts?
[EG "Norm needs a place to stay" does have an existential. Should
it be represented as such?]
As shown above, there are clearly at least two main decision times
which must be considered -- plan generation, and during plan execution.
[Are there others?]
In later case, should the information be preserved in some rationale,
or in the actual plan steps? I chose the latter, as the most canonical
location. (or should there be IF-THEN clauses in a rationale which decides?)
Have you devised a formalism for encoding meta-level statements --
eg about when to decide what to do, or how much (?many?) resources to expend
in deciding? Or, more generally, about what inference procedures to follow?
*****
My hope is that eventually this Planning System has a wide range of these
links; which are each well-understood -- each relation corresponding to
a predicate calculus formula. The user, I envision, will be able to add
on his own connectives, provided they are as well defined.
---
Thanks for your comments -
Russ
Msg sent who-knows-when to who-knows-where
Well, after diddling around a bit I've concocted a KLUDE-like thing,
which I'm getting set to embellish. I have questions about the liberties I
may take -- ie what are the constraints which are imposed on things like
the user's input specification. In particular, shall I assume the input
will always be in the english format used for this bike example? Is it
contrary to your/the Silicon Pencil's philosophy to expect the user to
enter his data in a different, constrained format, or to enter additional
information?
One proposal would be to expect him to enter "KeyWords" with
each plan step, and with each rationale. It is these words or phrases
which would be scanned for and matched against during the replanning
process; as opposed to the complete stream of English text. (The latter
is, of course, preserved; and can perhaps be used for other inferencing...)
There are many advantanges to this approach. First, these words would
delimit the set of terms which the Planner system would need to "know"
about -- for example, we could say that "Sunday" is a specialization of
"WeekEndDay", which is, in turn, a refinement of "Day". A similar sort
of link would indicate "Sunday" is a kind of "TimeUnit", ... As you may
have guessed, I'm proposing making each such key phrase a unit, and storing
on it whatever information is necessary, or could be used, to handle retrieval
and updates on the steps of the plan.
Realize this set of key phrases is open, in the strongest sense.
While inputting his plan, the user would be prompted to specify
the defination/use for each new key word he enters. He would, similarly,
be allowed to examine the existing body of keywords, with the option
of correcting or updating any with which he disagrees.
By the way, I'm trying to use this in my hacked up step0 model.
My quick and dirty approximation takes the words of the english text of
a plan step or rationalization, and degrees that all but the "noise words"
(such as A or HE) are the keywords of this statement. There are obvious
long-range problems with this purely syntactic approach (especially wrt
idioms), but for now it seemed reasonable... (Pf: See Yale.)
At some point we should have a second iteration of discussions;
mostly so I can improve my understanding of both the overall project
and my role within it.
What are your plans for the immediate future? If I don't see you
before this weekend, I hope you, Barbara and Aaron have a nice vacation.
Russ
-------
∂To: (%Rand-Ai Bill, Rick, Wescourt, Barbara, Norm, Mike) 17:24 29-May
Comments on Keith's Proposal
I read this message with an eye towards encoded the necessary data
in RLL. As my comments below may show, there does seem to be a
fairly good fit. (In many cases this is simply a property of any
object-centered data base; other features come for free on any system
built on InterLisp (IL); only a few seemed to require a less
"trivial" feature of RLL.)
[My comments are prefaced by *-*-*.]
--------
∂27 May 1981 1136-PDT Keith Wescourt <WESCOURT> Proposed features for demo system
To: Bill, Greiner, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
Here is a relatively unordered list of features to be considered
for the design of our demo system. "Rationale" for each proposed
item follows in an indented block surrounded by curly braces. I
have not yet added rationale for all the proposed features.
The system should combine plan rationale entry and question-answering
(retrieval) functions.
*-*-* RLL would provide each item with a name, which would permit the
*-*-* needed handle to re-access it. It is trivial to read (or even
*-*-* modify) one unit while still creating/editing another.
{
The user may have to refer to existing items when entering or
modifying a particular item.
The user may notice errors or deficiencies in database content
or structure during retrieval and wish to modify the database at
that time.
}
The command scanner should be specific to the system's command set.
{
Erroneous user inputs should not cause random things to occur
(e.g., delete all his/her files, invoke some other program, etc).
*-*-* First, as RLL is in IL, there is little the user could do
*-*-* (in ignorance) which would affect the outside environment
*-*-* (that is, anything outside IL).
*-*-* Also, many of the RLL's major destructive functions
*-*-* (such as DeleteUnit) are undoable.
The command scanner should support both concise and verbose input.
{
Variations of expertise with the system, both between and
within users, require a range of input detail for user comfort.
}
*-*-* RLL currently has no convenient input facility. Such an
*-*-* interface would have to be constructed, eventually.
The command scanner should provide interactive prompting (a la the
TOPS20 EXEC) including noise words, completion/recognition of input,
and explanation or enumeration of legal inputs in response to a
'help character'.
{
Users should not have to interrupt what they are doing to obtain
simple sorts of help.
*-*-* I know of hooks into IL which provide this. RLL has yet to use
*-*-* any of these.
Since the system may change rapidly, integrated on-line help may
be easier to maintain than off-line help.
*-*-* Each of the functions would be encoded as a unit. This documentation
*-*-* could be stored there, perhaps at various levels of verbosity.
*-*-* (Some thought would have to be given to the more general problem
*-*-* of deciding how to administer more general aide, of course.)
Completion/recognition helps teach users about acceptable concise
inputs.
*-*-* Once again IL has a host of such I/O functions which we can tap.
Enumeration of finite options is useful when the option set may
be routinely modified by normal user interactions.
*-*-* The unit associated with such functions can store these options,
*-*-* and perhaps make trivial, "optimizing" changes to the function's
*-*-* definition as these options are dynamically changed.
*-*-* (One such alteration would be to permit that function to provide
*-*-* completion/recognition of allowable options, when queried...)
}
Each 'item' in the database will be an object and associated
attributes, including in addition to it's content:
*-*-* Any of these could be implemented in any object-centered language.
*-*-* RLL would provide a ready mechanism for defining these slots --
*-*-* For example, one might say each such slot, S, has the property
*-*-* that each time a new value is stored on U:S (the S slot of the
*-*-* U unit), the value of U:TimeOfLastAlteration would be updated.
*-*-* A more complicated version might involve storing, say,
*-*-* the current context, or IN list of assumptions.
*-*-* These could be retrieved and examined later.
*-*-* (An economizing move might involve storing this sorta stuff in
*-*-* some global variables whenever a value is retrieved...)
an edit history-- a list of pointers to previous versions of the item.
{
Users might want to revert the database to an earlier form.
Users might want to examine how a specific item has evolved and
explore why.
}
the date of last modification
{
Users might want to know how up-to-date and item is.
Users might want to use this date as a qualifier for retrieval
}
the name of the last writer
{
Users might want to contact this person with questions not answerable
from the database itself.
Users might want to use the source of an item as a qualifier
for retrieval.
}
the reason for the last modification
{
This is rationale for the item's modification.
This information can be represented more compactly as an item
attribute than as a separate item in the database (e.g., it
is permanent and non-editable.
*-*-* Oh, so you think history can't be changed. We'd better finish this
*-*-* project before 1984...
*-*-* Seriously, this leads to an important point: RLL lets the user
*-*-* decide which of these attributes should be stored, and in what
*-*-* format. (For example, the time stamp alone might be sufficient
*-*-* to determine everything else you need -- IF accurate records
*-*-* were kept indicates who was editing this data base when, and
*-*-* the sorts of things he was then focussing on, and what his rationales
*-*-* were, ... This would involve storing the "dual" of the data base
*-*-* outlined above; and this IS possible to do in RLL.)
*-*-* Even these decisions could later be altered
*-*-* -- RLL will have the capability of
*-*-* converting from one format to the other, "invisibly". That is,
*-*-* the user would call upon the same access/unpdating functions,
*-*-* which would retrieve the
*-*-* same values. The difference would be that these functions would
*-*-* have been rewritten to look at different places.
*-*-* (To skeptics who challenge this claim: Much of this can be achieved
*-*-* using known canned algorithms.... [Each of the components would
*-*-* have sufficient self-knowledge to "know" which of these procedures
*-*-* is appropriate.] More complex versions involve constructing these
*-*-* procedures from sub-chunks -- like gluing together subprocedures into
*-*-* a working whole. The final leap would be automatic programming-isk --
*-*-* generating these programs from "first principles".
*-*-* I'll worry seriously about this only when those canned procedures
*-*-* prove insufficient...)
}
a list (possibly null) of keywords explicitly assigned to the item
{
Users can categorize items a priori in ways that would be
difficult, expensive, or impossible to do with pattern matching
on those items' content.
*-*-* Ok - this is sorta what I was doing. Perhaps this could be done
*-*-* pseudo-automatically:
*-*-* If the user stores that list of keywords, these would be used for
*-*-* any and all matching which occurs. On the other hand, the trusting
*-*-* use may omit this list, and allow RLL to fill it in. Various cute
*-*-* syntactic tricks could be used to extract the relevant-seeming
*-*-* phrases from the otherwise unused English text, and these would
*-*-* then be stored as that item's keywords, and used for those matching
*-*-* steps. (Alternatively the user would be asked if those words are
*-*-* appropriate, and allowed, then, to alter them as he sees fit.)
*-*-* [EG the routine the NS (news service) program uses is quite nice.]
*-*-* Anyway, the user would always be permitted to modify this list
*-*-* if he thinks it inaccurate, or simply inefficient.
*-*-* **** A first crack at this can be found in the file <CORE>UNITTED.ITEMS,
*-*-* which includes with each item a list of sloppily determined keywords.
*-*-* (The code which generated keywords from english text took all of half
*-*-* a day to write, and the results seem reasonable if not perfect.
*-*-* (The interested user is refered to <GREINER>MU..) I'm confident better
*-*-* results would come from more work along these lines.
}
a list (possibly null) of labeled pointers to other items
{
This a uniform method for representing a labeled, directed graph
structure.
We believe the structure of plan rationales can be represented
by labeled, directed graphs.
*-*-* Here, here! We should decide which links should be included for
*-*-* the initial system. (My message to Barbara contained a collection
*-*-* of first thoughts on this...)
*-*-* As it evolves, new links could readily be added.
*-*-* (This ability is inherent in object-centered frame-like systems;
*-*-* but it is RLL which makes this task easy.)
}
the 'owner' of the item
{
The database should provide accountability and explicit
responsibility for access control.
}
a list (possibly null) of legal writers of the item in addition to
the owner
{
The owner may wish to allow certain other users to change an item.
*-*-* Easy to achieve in RLL -- by using a PutValue function which checks
*-*-* the LegalWriters slots of U before permitting U:S to be changed.
*-*-* (Note many of these restriction would apply only to top level
*-*-* modifications; that is, those which the user does by hand.
*-*-* RLL's "truth maintenance" would still be
*-*-* permitted to do things like updating back pointers.)
*-*-* This LegalWriters slot should be defined to prevent its value from
*-*-* being changed by anyone. It could easily be designed to allow all members
*-*-* of a class of units to (cheaply) "inherit" the same group of writers.
}
a list (possibly null) of legal readers of the contents of an
item in addition to the owner
{
Access to certain information may have to be restricted
*-*-* Same process mentioned above, for GetValue.
}
[note: write/read access might be controlled via centrally defined
groups instead of lists stored with each item]
The system should interface with a message sending system to allow
easy notification of an item's readers/writers whenever the item is
modified.
*-*-* IL does allow this, but it might be tricky. Better would be
*-*-* to have a RussGreiner unit in the system, which "receives" all
*-*-* of these messages, and reports them to me when I enter this system.
{
Users should be able make certain others know about specific
changes.
Users should be able insure that they are notified when
specific items or classes of items have been changed
An explicit interface to a message system will provide for
more uniform and thus more easy to process notifications
(as opposed to arbitrary inter-user messages)
*-*-* Why? I assume by "message system" you mean the one the system
*-*-* provides (ala MM). I'd rather see all of my Pencil messages
*-*-* when I'm in a position to do something about them -- ie when I'm
*-*-* in its environment.
*-*-* Note also that there are other advantages to explicitly storing
*-*-* facts about the user him(her)self: RLL can hang a host of other
*-*-* specific facts about that person here -- such as "common typing
*-*-* error", to help when previously unknown words appear in the
*-*-* English text s/he typed, or when non-existant functions are invoked.
*-*-* "Level of expertise" could be stored, and used when printing out
*-*-* comments and error messages. (The list goes on...)
}
The system should maintain a local edit history for items modified
during a session. The permanent edit histories are updated from the
local histories only at the end of session or when the eser explicitly
gives a command to do so during a session.
*-*-* As before, RLL provides handles for this. The naive approach,
*-*-* of tagging each unit with the meta-information about its recent
*-*-* alterations, will consume a bit of space. There are more sophisticated
*-*-* ideas (eg writing each update on an external file) which may
*-*-* correspond to a different point on the time-space tradeoff.
*-*-* Which to use, of course, depends of this depends on the
*-*-* use of this data.
{
Any changes to the database should require an explicit
confirmation before they are available to other users.
Users should be able to introduce hypothetical information
and explore its consequences without affecting other users.
*-*-* Perhaps a Hendrix/Fikes-ian "Partitioned Semantic Network"
*-*-* would work here. RLL doesn't yet know about this, but
*-*-* would be easy to teach.
An item's permanent edit history should not be cluttered with
changes due to errors.
}
The system should support manipulation of items via their edit
history-- i.e., reverting specific items or classes of items to
prior states, where class should be taken to mean any set of
items that can be selected via their attribute values. For example,
"revert all items with keyword USSR, written by Jones after 1-Mar-81
to their state on 1-Mar-81".
*-*-* Do realize that this is really meta-information -- ie not about
*-*-* the planning task per se, but rather about how and when the
*-*-* the plan was constructed. While I agree it should handled and
*-*-* used, the basic mechanisms may need to be different
*-*-* from the tools used for manipulating data in the base domain.
*-*-* (This is NOT the case now in RLL -- one uses the same access
*-*-* functions for any facts, regardless of (meta-)level.)
There should be three modes for entering/modifying items
1) unrestricted via a full screen editor
2) selective via a passive, attribute-at-a-time command scanner
3) selective via an dynamic, attribute-at-a-time menu system
*-*-* Mike Genesereth and I worked out a list of parameters which
*-*-* serve to characterize an editor. The above list does not
*-*-* mention, for example, when the data base updates (eg creating
*-*-* backpointers, or invalidating dependent values) are performed.
*-*-* (If you think it relevent I'll search for that list, and forward
*-*-* it along.)
The validity of entries and changes should be checked at the time
they are entered.
*-*-* Why? Perhaps some fallacious value for a slot should be allowed
*-*-* temporarily --
*-*-* for example, you may wish to characterize some intensional
*-*-* object for a while before "anchoring" it. Or you may want
*-*-* to store a value V in U:S before actually defining V.
*-*-* (I'm not advocating that approach, just commenting that I don't
*-*-* find your assumption obvious.)
This includes the legality of attributes and
their values (possible for some types of values like dates, keywords).
This checking is virtually automatic for the selective input modes,
because the menu system is driven by the syntax and semantics of
the legal grammar and the command scanner can apply the same grammar
either a character-at-a-time or a word-at-a-time to typed input.
For unrestricted input, a parser would have to process the text
returned from the editor.
Items should be retrievable by specifying any combination of attributes
and values. Any value for any attribute (not just the 'content' of the
item) can be represented in some sort of general expression grammar.
*-*-* RLL does not yet have any such matcher. Given its basis on CORLL
*-*-* (which permits most units to be stored on external disk most of
*-*-* the time) this process might prove quite expensive (requiring
*-*-* a slew of things to be swapped in and checked.) Of course this
*-*-* depends critically on how the data is stored, and which
*-*-* combination of "fields" serve as keys. [I question whether you
*-*-* really mean ANY value of ANY attribute.]
*-*-* (EG if the key is only one
*-*-* field, this retrieval could be driven by a backpointer from the
*-*-* unit which represents that key value.)
*-*-* Anyway, as this may be a crucial factor in deciding on the
*-*-* representation to use, we should discuss this at length.
Retrieval via the pointers attribute should be a special mode supported
by graphics i/o. That is, the user should be able to "move" around in
the network graphically displayed to show the connections (relationships)
between items. Three movement modes should be available: commands from
the keyboard that allow arbitrary movement; local moves via commands
(e.g., arrow keys) from a keypad; analog control from a joystick/trackball
type device. Graphic display should be zoomable to display different
levels of detail.
*-*-* I've put no graphics facilities into RLL. Doug, however, has spent
*-*-* a while fixing such a system on DLISP, which I think would accomodate
*-*-* just this sort of perusal.
The output of retrievals should be filterable by attributes so the user sees
only the part of the item he/she wants.
*-*-* The (weak) user model can house just this sort of information;
*-*-* which the retrieval functions can use.
The output of retrievals should be divertable|spliceable to hard-copy devices.
*-*-* No comment.
Transcripts of sessions with the system should be savable (non-trivial if
some input is from analog devices and some output is graphic).
*-*-* No comment.
All retrieval concepts involving pointers-- e.g., find every item of type
'planstep' that DEPENDS on an item with keyword 'rain'-- should be defined
in terms of a few primitive operations for traversing networks and should
be modifiable/augmentable by the user. The definition language should
allow specification of the distance between the items, the pointer types
required for the concept, and the pointer types that disallow the
concept.
*-*-* This is right up RLL's alley. Much of my time has been spend defining
*-*-* easy means for just this sort of transversal.
The system should have an interface for inspecting and modifying its
components: retrieval concepts, output filters, default input modes,
and any other parameters. This interface should be uniform with that
used to inspect and modify the item database wherever possible.
*-*-* 100% agreement. Every part of the RLL system is (or will soon be)
*-*-* this transparent, and modifiable. The only disadvantage of this
*-*-* approach is the non-trivial start-up time; from then on the wins
*-*-* are tremendous.
---------------
*-*-* I did want to conclude by explaining many of the hedges you
*-*-* may have noted above -- RLL's big plus is NOT its current selection
*-*-* of currently implemented features; rather, it is its abundance
*-*-* of available hooks, which permit it to readily code up those
*-*-* particular components.
*-*-* The fact that many of the things mentioned above do not now exist
*-*-* is not a serious limitation -- it only reflects the fact that I
*-*-* have not needed those facilities.
*-*-* I do welcome the opportunity to enhance
*-*-* the RLL system by coding up these additions...
*-*-* As with any new code there is the obvious problem that it will be untested,
*-*-* and possibly do the wrong things.
*-*-* I think the RLL-coding-style, which insists on making things explicit
*-*-* whenever possible, does lead to less buggy initial code.
End of pep talk. If any of my claims above seem outlandish, or simply untrue,
please let me know. (I've been known to exaggerate before.)
Russ
∂29-May-81 0937 RICK at RAND-AI rll
To: greiner at RAND-AI
cc: rick at RAND-AI, rdg at SU-AI
∂TO RICK@Rand-Ai 18:17 29-May
RLL revealed!
Russ:
I've now read the rll papers you gave me and I'm impressed.
Now I have some questions.
(1) How do you do unit-to-disk and v.v. swapping?
Specifically, how efficient is the indexing and loading?
What makes for efficient retrieval of units?
*-*-*
[Does "v.v." stand for vice versa?]
The basic swapping is performed by a package Dave Smith wrote called CORLL.
(I'll send you a manual at first convenience.)
The basic accessing functions all check first to see if the unit
in question in currently in core (as this is the assumed standard case),
reading that unit in only if necessary.
Units are swapped out, using a simplified LRU scheme, during certain
garbage collections, under certain conditions.
(Dave is just now converting CORLL over to use IL's HASH package,
rather than the one he wrote, by the way. I think this will make
the accesses yet faster, and require less space. We'll see...)
The only retrieval key for a unit is its name. If you want a more
versatile scheme, I imagine it could be written up in a day or two.
*-*-*
(2) Can we handle upto 3000 units in RLL? Can we feasibly
use RLL for plan rationale items, one per unit. How efficient
would it be to store text strings of several hundred characters
within a slot of a unit?
*-*-*
RLL currently handles about 1000 units, with no problems.
Yes, each rationale item does deserve a unit; and I believe RLL could
accomodate that without any trouble. It was the keywords I was
worried about. RLL may have a hard time holding a large subset of the
English language in "core". Of course, this is only necessary if my
ad hoc scheme is used -- and seemed a strong reason to reject that
approach.
I think the limiting factor will NOT be CORLL -- it makes the storage
limitations about the size of disk, not IL's 256K.
Rather, IL has an inflexible upper bound for atom names, of 32K.
While we're still a long way from that, it may take some tricks
to sidestep this problem. Mark Stefik's LRS system allows units
to have numeric "names" -- like (Transistor . 45). I imagine CORLL
could handle that without too much fuss. (After all, names like
R-342 are essentially isomorphic to that.)
Text strings - here I don't know. Yes, you could store them, no problem.
However, we're at IL's mercy when it comes to retreiving them, depending
on whether that space is reusable (atom name space is NOT). If not, we may
be able to sidestep that problem by keeping that english text on some external
file, out of IL's jurisdiction. But let me first check -- this contortion
may simply not be necessary.
*-*-*
(3) Is RLL mature enough for me to consider using it for the
project?
*-*-*
Believe it or not, I think so. It seems to have attains a nice
degree of sturdiness (as opposed to fragility), at least for all the
tasks I've assigned it. Yes, several things will have to be added on;
but most of that will be, little more that LISP coding.
Those parts which only RLL can provide are, I feel, fairly complete.
Anyway, I will certainly be available to provide both quick patches
and, after consultations with experts like yourself, appropriate
alterations to underlying code, as needed.
It would be a good test of competence, for both RLL and me.
My response to Keith's letter should indicate some of my beliefs
and convictions, and may give clues about RLL's readiness.
*-*-*
-----
Anyway, we should continue to discuss this, as I do not want to be
in a critical bottleneck in this overall project; especially as
thesis time rolls around. Let me outline what I would consider an
ideal scenario, should RLL be used:
(i) I would first provide the necessary "indoctrination" into
the use and style of the RLL "way of life".
(I did personally thank Stan for that useful insight.)
(ii) As we collectively designed the overall system,
I would show how RLL was actually encoding the various different parts.
At least at first, I would remain visible, to fix up breaks
(which, sigh, I know will occur,)
hopefully with some recent initiates looking over my shoulder.
(iii) After not too long, (pessimistically a month,)
this RLL system can be pseudo-frozen. (IE only changed as necessary to fix
major implementation bugs -- not design/conceptual errors made earlier.)
Here quantities of data can be dumped in.
While remaining on emergency call, I can beg out of this aspect of the project,
to work on other parts of it, or thesis sorts of stuff, or whatever.
(iv) After a few months, there will undoubtedly be realizations
of shortcomings of this implementation of the workbench.
Here the now experienced RLLers and I could collaberate to reconfigure
the system into the improved second release.
(v) From here on I think I will be expendible. By now Rand will have a
slew of artists who can use and expand their RLL environment, and provide
contributions to the RLL community. (Sounds like Mom and Apple Pie, don't it.)
-----
[I should make explicit one of my biggest worries: Although my ego is
somewhat tied up in RLL, my thesis will not be. There may be extended periods
of time over which I will have other higher-priority (ie thesis-related)
concerns; and here I would prefer to feel comfortable packing off from this
project. Now I do think I can become gradually less needed -- there's
not all that much to RLL itself, beyond the rll concept.
Once that is communicated, the existing code is fairly straight forward to
understand, and the future code can be as easily incorporated.
Or at least that's my current work hypothesis (no pun intended).]
Russ
∂29 May 1981 1322-PDT RICK Today's design contributions
To: wescourt, bill, greiner, randvax!norm at RAND-UNIX, randvax!barbara at RAND-UNIX
cc: rick
GUIDELINES: KISS, ONION (incremental developments)
THINGS TO DO:
Elicit/Enter new items
Display
Edit/Alter
Historical change/update/feedback
Analyze/verify/re-verify/hypothesize
Interrogate: What specifically for replanning?
Brief
WHY DEMONSTRATE?
1. We need to sell our work
Graphics good for this
Analysis capability good for this
2. We need it for experimental & conceptual development
This motivates edit, display and hardcopy capabilities
In support of brief, interrogate, and elicit capabilities
3. We need milestones
Should be realistic, achievable, incremental, satisfying
4. We need it for project management
This motivates display, update, ...
5. We need to communicate to outsiders
POINTS TO DEMONSTRATE:
1. Recognizable problem/scale/realism
2. Improved approach/techniques/already done
3. New capabilities/science/already established
4. Specific promising avenues of further R&D/worthy of R&D support
5. Applicability in near team/worthy of operational support
IMPLEMENTATION ALTERNATIVES:
Case 1: Continue as much as possible with VAX/UNIX/C
Pro:
Existing software
Norm comitted
Good editor
MH candidate
Everyone knows E & MH
UNIX has good software tools
Carries forward into other unix machine environments (or ADA)
We learn unix
Con:
Software modifiability low
Only norm is an ace
Analysis is difficult without evaluable expressions
Software must be designed before implemented in C
Norm worries about graphics => no one else to program text part of WB
Case 2: Move as much as possible to a collection o ROIE programs on the 20
Pro:
3 very good programmers+BHR possible
I'm sure much of it can be done well in the language
Frees norm for graphics
Good editor & possibly Hermes & SPELL & PCL
KW knows lots of the 20 software
Carries forward into the dolphins nicely
Con:
Very slow for large databases
Would probably have to implement indexed/swappable units OR
woul have to use many fils
Probably wouldn't be practical without IPCF capability which isn't
expected until Sept
<= multiple rosies
<= memory limits on rosie
Relational language is quite hard to do in ROSIE
Evaluable expressions hard in ROSIE
Case 3: Move to RLL (with INTERLISP)
Pro:
Can handle all items in its own KB
Can handle relational language
Should be possible to couple a front-end to RLL from ELLIE
for many interactions
Russ is an ace on RLL
Dependency maintenance should be easiest in RLL
Frees Norm for graphics
Con:
Doesn't support strings & string matching well
Who can understand it? --> Rick (.7), KW (.7), RDG (.95)
BS is willing to learn it
Only Henry knows ELLIE, but KW should know it too
Very risky, because we don't know we can use it effectively
Makes RHR responsible for lots of software
Case 4: Do a mix of C & ROSIE
Pro:
Rosie can run c programs via arpanet
Each person can program
Con:
Requires arpanet & lots of pattern matching by ROSIE which is slow
Case 5: Mimic small-talk <e.g., use simula>
Pro:
Prepare for small-talk as the eventual RIGHT language
Good for long term if we stick to this software base
Con:
Lots of additional work required now
Much less to demo by September
Bad for long term if we suspect we'll drastically change our
software later
APPARENT NEEDS IN PRIORITY BEST APPROACH APPARENT COST
1. Graphics display NS/BS/MW: done in C NS all summer
1.1 Networks Genisco or AED
1.2 Highlight dependencies
1.3 Hardcopy plans I like BHR ideas
1.4 Hardcopy rationales ditto
2. Analysis RHR all summer
1.1 Automated value changes RHR/KW:RLL or ROSIE Need multiple DBs
1.2 Constraint propagation ROSIE=>major changes
1.3 Manual traversal Tight couple to graphx for unevaled exprs
(pass item names) Duplicated DB on VAX
3. Entry/editing/maintenance KW/NS: PCL,ELLIE,EMACS KW all summer
Parse to produce items
in different formats
Translation between user
form and RLL/ROSIE/UNIX
inputs
4. Retrieval/Question Answering BS/BHR: ROSIE or RLL BS all summer
Develop plan KB and index
Minimize string searching
Employ new interlisp string
matcher from KW where needed
5. Briefing BHR/RHR: ROSIE BHR all summer
Develop plan hierarchies
Develop interestingness
Locate interesting elements
INTERMEDIATE MILESTONES:
Fri 5 Jun Initial mgt plan prepared
Tues 9 Jun KW formats the mgt plan & distributes it
Fri 12 Jun Each person brings a concrete illustration of his part
Fri 19 Jun Each person brings a concrete design for his part
(that can be done in 1 month)
Fri 24 Jul Initial implementations demonstrable
Fri 31 Jul Revised designs for 1st functional system
Fri 14 Aug First functional system
PRIMITIVE SYSTEM ELEMENTS:
RETRIEVAL: <item descriptions>+<indexed retrievals>
language, linguistic generality;
relationships among items
STRUCTURE: <relational language>
types of relations, pointing to items, formation/alteration
copying sub-structures
intra-item variables
inter-item constraints
GRAPHICS: windowing
zooming <descent,ascent, scale change>
clipping
boxes, links, labels, content
DEPENDENCY MAINTENANCE:
ramify constraints
detect inconsistencies
try to solve constraints
-------
---------------
-------
∂TO Barbara@Rand-Ai 12:36 4-Jun
Response to Barbara's comments
*** I apparently didn't ruffle any feathers enough to get
*** any other response to my last message, besides yours.
*** Did you mail that set of comments (your response to my message) to the
*** other group members? If so, please feel free to forward
*** this reaction to them as well, if you think it would be relevant...
wrt 2)
The protocol contains some instances of well-structured
arguments of the form: Premise A, Premise B, ..., Therefore Conclusion.
In other cases, a statement in the protocol is supported by a list
of more or less independent reasons. Some statements benefit from both
types of support and there are probably others as well.
In any case, we might want to explicate the nature of the argument
underlying a particular statement and the exact
relationships among its constituents.
Yes, I heartily agree there are many other types of relations
beyond those few I mentioned.
In particular, there were many times
when a whole slew of independent
things were needed to reach some conclusion --
ie instantiated your first sub-example, Structured arguments.
(I remember noting how woefully awkward the proposed slot-based
formalism became in such situations...)
In all those cases the relationship joined a
n-1 tuple of premise rationales with a concluding rationale.
[Q: Are there other cases?]
Clearly there is some type of inferencing going on in this situation.
I would feel uncomfortable unless such rule(s)
are explicitly stated.
(For example, the rule might be modus ponens;
or it may be some user based deductive scheme.)
[Q: Do others agree such rules should be explictly stated?]
In these situations perhaps we should play theorem checker (ala FOL),
and force the user to indicate how each deduced statement was derived,
and from just which premises.
If so, we should begin to define his (starting) vocabulary of allowed
operations. (which should certainly include at least the logical set
FOL gives -- eg And-Introduction, ForEvery-Instantionation, Modus Ponens.)
He should be able, eventually, to define his own -- using, perhaps, his
own ideas of "proof".
(This does lead to one important worry:
deductions may no longer have the nice property of being purely syntactic.
Of course, this may not be much of a loss,
as that derivation process was always intractable anyway;
and we never `really' intended the Workbench to work unassisted, and ...)
Realize that then the second example,
Example: Domain-specific functional relationships
Resource requirements are a major consideration in the bike trip plan.
It might be useful to code them explicitly so that we could easily
answer questions like--How much money does Norm need and which parts of
the plan require cash?
becomes essentially a special case, once we have a handle on inferencing --
ie a set of rationale can be used to "prove" a concluding
rationale, based on a user defined inference rule.
(eg the "resource allocation rule" would be called to justify the conclusion
"Norm must have money" whenever the "Norm might need to spend money" premise
occurs.)
Proposal: (<= read unsubstantiated first thoughts)
This capability might be implemented by simply considering
each jump as "application" of a lemma
-- ie this conclusion does follow logically (ie using only the
initial operators) from the premise, but as that process takes several steps
we encoded it into a single rule.
That user-defined operator would then be just a "macro", which, when
instantiated by the premise, returned the conclusion.
(Note it may have to check a set of assumption along the way...)
This lemma-idea is certainly true in some cases
-- such as the one trivial example shown above.
Other cases might involve, for example, non-monotonicities;
and so could not have followed
(first-order, domain-[as opposed to meta-]level) logically.
Hence, to be as general as we would like, these lemmas may have to be in
some higher-order logic.
(This will assuredly force us to worry about reason-maintenance at various
levels -- with all the problems that involves...)
Comments/refutations/screams of anguish?
wrt 3)
As I understand your approach to this problem, you are trying to
enumerate a "complete" set of relationships, capable of capturing
everything planners might express during a planning episode.
Another approach would be to enumerate those relationships that
would provide useful functions during plan review, plan evaluation,
plan modification, etc. What functions will the relationships you proposed
provide? What questions will they answer?
How will they help somone understand or use the rationale?
Several comments:
i) Actually I was just reacting to the way the plans were displayed --
I felt that just indentation, by itself, could not possibly convey
all the facts necessary for understanding a plan.
It is possible, for various psychological-type reasons,
that that type of listing may still be the best hardcopy form for
presenting the plan to a user. However I feel the user should be able
to determine why a particular UNDERLING fell under a HEAD -- just how
they were related.
Before we can store such information it is essential
to at least map out the space of possible relations.
That list I mailed was
designed to be a first crack at that categorization --
an ennumeration of the diverse set of things one may want to use in
connecting two rationales...
ii) No, I never felt any such list will be sufficient to capture *everything*
any planner would want to express.
I was hoping only for a good working subset.
My philosophy is to provide the user with two things:
First, that almost-spanning subset, including relevant
terms, connective, inference schemes, etc.
Second is a set of mechanisms, which can be used to
help those future planners to expand that pre-existing vocabulary
into the one he wants to use.
I'll come back to this point again in "wrt 6)", below.
iii) This does lead to the question of what would constitute a good
initial collection of connectives.
For this I need the data which will come from the replanning experiments
you're now performing. Any word on when such output will filter out to
me here? The data I'm collected thru introspection alone I'm found to
be too limited.
wrt 4)
I'm quite willing to make lexical substitutions in favor of conformity.
Which terms should I redefine/incorporate?
wrt 5)
Another useful "time" (in addition to plan generation and plan execution)
is plan modification time. How do we keep track of successive states
of an evolving plan and their relationships to one another?
This is a good point - Keith, in his recent message, was clearly quite
concerned that the history of a plan's derivation and modification
be preserved.
This is a meta-level connective, pertaining not to the plan per se,
but rather to the planning process, and the planners themselves
-- their oversights, ignorance (eg about faulty tacit assumption), etc.
[Notice that the plan execution time links are not really meta-level facts:
Yes, each is based on the implicit meta-level assertions that
"the planners do not know some X", but that "X will be known later".
(where X is some proposition, such as "Norm <is> tired at 4:20PM on Feb 3".)
However one could say the same (vacuous) type of thing about the plan
generation time assertions -- namely that "the planners do know that X",
and used it to formulate this part of the plan.]
Anyway I agree these links should be preserved -- but I reiterate my point
that they need not be stored in the same manner that is used for standard
links.
(This is a subtlety to this point:
The "PlanStep#4 was replaced by PlanStep#4'" link is such a meta-level
connection, and need not ever be visible to anyone examining the final plan.
However, the facts that
"PlanStep#4 looses BECAUSE of fact X",
"PlanStep#4' is immune to the effects of fact X",
together with the (implicit or explicit) marks that
"PlanStep#4 is IN",
"PlanStep#4' is OUT",
are useful, and should remain.)
wrt 6)
General issues of timing planned actions are apt to be more complex than
"before," "after," and "until." Consider: at 5:00, during the ascent,
within 60 seconds of landing, for at least two hours.
Yes, time is a complex beast. So is space (as in spatial relations),
intentions, and naive physics (ie enough [?superficial?] understanding of
how things interact to get by in the world).
I personally feel the "right" approach is to provide the
user with a host of pre-defined terms and relations which we (the Silicon
Pencil's designers) happened to feel were natural, and, for our tasks at
least, sufficient.
Clearly many of these "domain independent" things
should be in the domains mentioned above.
Of course the particular things we provide are guaranteed NOT
to correspond to the user's intuitions.
This is why I believe it is important to give the user the tools he will
need to construct his own parts, or "twiddle" those parts we provided.
Those initial peices are only there to give the user a flying start.
-----
Anyway, I may have oversold a bunch of claims above...
While I do feel the eventual, mature system should have these sorts of
capabilities, certainly many of these attributes can be omitted in the first
few implementations; as long as we can add them on later, as need arises.
My major point is that we keep these ideas in mind throughout our design,
so such upgrading are easy to perform.
[Hmm -- none of the various lists include the planning idea of
"background ideas/motifs". Any ideas on how to incorporate this?
(I know Wilensky has given a bit of thought to this point recently...)]
----
Russ
∂ 4 Jun 1981 1036-PDT Keith Wescourt <WESCOURT> Re: Comments on Keith's Proposal
To: Greiner
cc: Bill, Rick, Wescourt, Barbara, Norm at RAND-AI, Mike
Russ,
Sorry to take so long in responding to the thoughtful annotations
you provided to my proposed list of features/capabilities for
the Workbench-0 design. In the interim, some of these,
especially those involving access control and "edit histories"
have been deferred to later implementations of Workbench. I am
currently focussing on our plan/design for user entry and
modification of items in the Workbench database. As a result of
conversations with Rick and your comments on my initial proposals
my current planning includes a role for RLL (and IL). I am
working on the details now and your comments are serving to guide
my decisions about which functions I should expect to be
able to use RLL for. They have also caused me to place learning
RLL on my personal agenda.
When is your next visit here? You and I should plan to spend
some time in a one-on-one meeting then. You will have access to
my current planning before then, so you can think about it before
we meet.
Keith
-------
∂23-Jun-81 0647 rick at RAND-UNIX overall design and components plus interfaces -- discussion notes
to: planner at RAND-UNIX, rdg at SU-AI
Item-type: Specification
Status: In
Pro: these concepts were discussed in the meeting on 22 jun 81
Pro: this design uses independent modules mediated by retrieval, each
providing its own user interface
Con: Norm thinks there should be a uniform interface to the workbench
Pro: rick thinks the initial workbench need not have a uniform interface
and that a uniform interface would take 6 months to develop
From: rick at RAND-UNIX
The major components of the workbench identified were:
1. a selector (switch) at the user interface on TOPS20 that selects
one of the other modules for use by the user
2. entry (for creating and modifying plans)
entry sends create-item, modify-item, and retrieve-item
requests to retrieval
3. briefing
4. analysis
5. query
6. grafix
7. retrieval (plus database)
Two other components that were identified but whose implementation remains
unclear include:
8. user profiles
9. concept database (a taxonomy of concepts used by various modules)
We decided that these two components may either be implemented
within the separate modules that require them or may be added to the
specifications for entry and retrieval and database if they seem
generic to workbench applications.
We discussed the three-basic functions of retrieval, FIND, RAMIFY, and
EXTRACT, and clarified the need for recursivity (of find/ramify specs)
within any find request. An example of such a recursive find request might
be "Find every item whose keywords include "John" and whose Pro items
have (status = OUT and con items who have (...))". The syntax for
recursive find-specs needs to be done and so does the mechanism for
database searching.
We agreed again that each person on the project has primary areas of
responsibility which cover all possible tasks within that area. Therefore,
each person may be requested by others to implement capabilities they need.
Discussion with Norm - 19 June 1981
Norm wants to store a several specific graphics-related pieces of information,
and be able to retrieve such data, on demand (during this, or subsequent,
editing sessions).
In his model, such information will go thru ENTRY (read Keith's
routines) -- at which stage they might be augmented or enhanced.
[?Keith - do you agree?]
I've listed below the types of data which seems necessary, followed
by a scenario overviewing the sort of interactions which use such facts.
This is followed with a proposal for the interface, and finally, with
a few outstanding questions.
-----
1. A (weak) user model -- to indicate which set of colors should
be used; or what types of lines to use for CON links during a demo.
These facts would be used to answer a limited set of questions about
this user's preferred (or default) settings for various parameters.
In addition to standard sorts of people - like Bill or Russ - it will
house info about "Generic individuals", such as the TypicalUser, or
TypicalWBHacker.
[Keith - you might use this set of units to store "verbosity", ...]
2. Facts about the actual displays --
That is, we need functions which return (pointers to)
the actual translation tables for a display.
This function takes 3 arguments:
the particular monitor being used,
the environment (this includes LightSetting, Time Of Day, and who knows
what else),
and the "effective user" (eg DefaultUser, or Russ, or Demonstatee - see 1.).
Proposed algorithm to find the entry (translation table) that matches
this particular set of parameters.
i. See if there is currently an entry which equal these parameters
(eg do a simple look up).
ii. See if these is a default setting for this monitor and user (ie
ignore the environment).
iii. See if this monitor has a default setting (ignoring user and environment.)
iv. Use the absolute default table.
(all of this comes almost for free using RLL's defaulting mechanism...)
3. Data about drawing lines -- such as
Red is row 37 of the translation table.
Deny-Lines are Maroon, and Blink, and are NOT Dashed.
IN-Links are drawn as Assert-Lines.
4. Some "Display Facts" about the ITEM nodes -- eg that X and Y should
be "at the same level" (read same Y position); or that X should come
before Y (to its left) when printed.
------
The data flow would be both ways -- GRAFIX would, on occasion, state
that "the user says this setting is good", but more often it will be
asking for data. In case (i) RETRIEVAL will store this table-setting;
to be retrieved as need arises. (Note ENTRY or someone will have to know
the current setting for the environment (eg current absolute time, and
total session time so far) and the user.
[?: Can I infer facts about more general classes of users, (eg WB-Hackers)
or just this specific one, (here Russ)?]
------
Scenario:
A)
Grafix - Entry: I need to draw a CON line. What color should it be?
Entry - Retrie: (FindGrafix (Color CON))
Retrie - Entry: Who is the user?
Entry - Retrie: Rick
Retrie - Entry: Row 37 of translation table
Entry - Grafix: 37
B)
Grafix - Entry: This setting is good! - 100101101...
Entry - Retrie: (StoreTable 100101101... (Russ (2:13 19:43 ...) Mon#3))
Retrie - Entry: Done.
C)
Entry - Retrie: (NewUser Norm)
Retrie - Entry: (NewTable 101001111....)
Entry - Grafix: "101001111..."
-----
At some point Keith & I should define a syntax which permits new facts
to be stored about (non-item) objects. For example,
(CreateObject Russ (Isa (Person) LikesColors (Red Green) ...))
(CreateObject Chartuese (Isa (Color) SimilarTo (Blue Green)
RowInTranslateTable 103 ...))
...
(ModifyObject Russ (LikesColors (Green) HatesColor (Red)
Nuances ((PleaseAvoid Blinking) (Be concise))...))
...
Or course data will have to go the other way:
(FindGrafix (Russ LikesColors)) - this would return (Green).
You get the idea. (Comment: we will probably need this sort of
fact-passing for general objects, anyway -- eg to assert facts
about Hilliness (eg it is the antonym of Flatness, and relevant to...))
Anyway, Keith, Norm and I should get together to figure how we should
communicate amoungst ourselves -- eg should I say
(TellGraphics (Table "101100001..."))
and if so, how will Keith further this to Norm?
-----
Other remaining issues:
Must I go thru ENTRY to contact GRAFIX; and vice versa?
Who should be responsible for storing various session-dependent facts?
I'm assuming RETRIEVAL (ie RLL) will house all permanent facts --
that is, things to be used from session from session -- but there
are many facts which pertain only locally, and only to this editting
session. Should RLL store these, and force ENTRY to request such
data every time? Or should both of use keep copies of such facts?
Or, as the scenarios above assumed, leave them only with ENTRY?
Should the user have any direct say in these screen-related matters?
For example, that he'd rather see OUT-Links as Magenta (skipping
a few levels), or (addressing the more general issue of user
profiles:) that he no longer thinks of himself as a novice, and
could ENTRY please stop talking down at him, etc.
-----
These are sloppy first guesses at solving a number of these issues.
Comments from other people people on these proposals will be greatly
appreciated.
Thanks,
Russ
-------
∂16 Jul 1981 14:53-PDT preliminary database specifications barbara at RAND-UNIX
Item-type: Specification
Status: In
Succeeds: item 186
Pro: this item incorporates information about the master plan item
To: planner at RAND-UNIX
the database contains two classes of items, plan items and rationale items.
plan items describe elements of the plan. rationale items describe
elements of the rationale. additional description and specifications for
each appear below.
plan items:
there is a master plan items that subsumes (via the sub pointer) all
other plan items.
other plan items represent each of three different types of plan elements,
goals, specs, and tasks. goals are the motivations, objectives, and
guiding philosophies of the project (e.g., develop an impressive demo by
september 1, build the demo around a real problem, KISS, ONION).
specs are system specifications, that is, functional descriptions of
the components and sub-components of the system we will develop to
satisfy project goals (e.g., analysis, graphics, briefing, briefing
a project leader, briefing a project leader on the plan). Tasks
are the activities project staff will carry out to implement specs and
achieve goals.
plan items form a basically hierarchical network with the master plan item
as the highest-level node. it has three immediate subordinates, the
highest-level goal item, spec item, and task item. (this means that each
type of plan item must have exactly one highest-level item, namely the
one whose -sub is the master node.) the remaining goals of each type
form roughly hierarchical sub-networks under their respective highest-level
items. the network is only basically hierarchical because some items
can be sub's for more than one higher-order item. also,
arbitrary pairs of items may be related via dep, req, and alt pointers.
plan items comprise the following information:
content: subject
author
label (for graphics <= 20 chars)
syntax
text
attributes: class: plan
type: master/goal/spec/task
status: in/out
staff: [responsible staff designators] (optional)
budget: [$ or name-days?] (optional)
resources: [equipment, other?] (optional)
due: [date] (optional)
done: [date] (optional)
pointers: sub[ordinate] (points to other plan elements of same type)
-sub (inverse of sub)
alt[ernative] (points to other plan elements of same type)
-alt (inverse of alt)
req[uirement] (points to other plan elements of same type)
-req (inverse of req)
cor[outine] (points to other plan elements of same type
dep[ends on] (if type = goal, points to specs or tasks;
if type = spec, points to tasks
if type = task, no dep pointers)
-dep (inverse of dep)
pro (points to reasons)
con (points to reasons)
Note: sub & -sub define the plan element "hierarchy"
alt, req & -req, & cor further relate items within a hierarchy
dep & -dep relate items representing two different
types of plan elements
pro & con relate plan items to rationale items
(and rationale items to one another)
rationale items:
rationale items represent each of three different types of rationale elements,
reasons, assumptions, and rules. reasons are the immediate justifications for
particular plan items (e.g., the KISS heuristic is a prerequisite for
r&d success). Assumptions are the beliefs, facts, data, etc.
uncerlying particular reasons or underlying other assumptions or rules
(e.g., the hearsayII project used the
KISS heuristic). Rules are the methods by which assumptions are
used to infer reasons, assumptions, or other rules
(e.g., if many successful r&d projects used
heuristic h, h is required for r&d success).
the rationale items should form multiple hierarchies. the highest-level
node in each hierarchy is the plan element being rationalized. it
subsumes a number of reasons via pro and con pointers. these, in turn
subsume assumptions and rules via pro and con pointers, and so forth.
rationale items comprise the following information:
content: subject
author
label
syntax
text
attributes: class: rationale
type: reason/assumption/rule
status: in/out
confidence: certain/confident/believe/doubt/deny
pointers: pro (points to supporting assumptions and rules)
-pro (inverse of pro; n.b., if type = reason, points to
a plan item)
con (points to contradicting assumptions and rules)
-con (inverse of con; n.b., if type = reason, points to
a plan item)
∂TO Rick@Rand-Ai 13:39 10-Aug
Status
Rick -
This brief status report is in response to my feelings of both delinquency
(at not periodically posting you about my progress) and frustration (read
on). To account for my recent actions: Basically I've been doing general
fix-up and enhancement work to RLL these days -- adding on features which
I believe will make writing the actual retrieval module easier.
I could see little sense writing actual code for this module until many of
the relevant details are tied down. Towards this objective, I've sent
various messages to assorted project members; and am currently awaiting
their respective responses. Included in this list are messages
* to Barbara - 4 June 81
* to Norm - 19 June 81
* to Keith - 24 July 81
* to Keith - 29 July 81
(I think I've CCed you on all of these -- I have retained copies if you'd
like to re-examine any of them...) Anyway, any comments on what else I
should currently be doing?
---Other fronts---
I've prepared, and sorta presented an RLL demo, which I'll be able to show
youse guys my next visit there. Hopefully by then my proto-primer draft
will have matured into a usable document; which I'll, of course, bring
along to distribute.
$$ - To avoid hassles with the Stanford bureaucracy, I have charged Rand
for only one work-day per week all along. In the process, I've accrued an
excess of several days in the process. Unless you object, I'll discharge
(?is that the correct term?) some of these days by submitting bills for
the week of IJCAI and the next "vacation" week. Is that ok?
From the distant backlands of Palo Alto,
Russ
∂10-Aug-81 1650 RICK at RAND-AI Re: Status
To: RDG at SU-AI
cc: RICK at RAND-AI
In-Reply-To: Your message of 10-Aug-81 1339-PDT
Russ:
Yes, it's fine to charge the way you propose. As for waiting on
others, please prompt anybody for any unfilled needs. I'm counting on
using your module real soon (read 5 weeks, since I'll be travelling/
vacating starting in 11 days). I infer that you and Keith should now be
on the verge of integrating working systems. Wednesday, I'll be putting
together the plan for the Sept demo. You and Keith can coordinate on
getting it together in my absence.
Looking forward to putting on a show!
Keep the cards & letters coming.
Rick
∂19 Aug 1981 1351-PDT WESCOURT at RAND-AI Composing match/get specs to retrieval by entry
To: Greiner
Russ,
I've been struggling a bit with getting the entry parser to produce
the 'Find' and 'Get' structures you defined in your message
dated 29 Jul 1981 1424 PDT (from RDG@SU-AI). {{TASK.RND[RDG,DBL]/33p}}
I think it is simply
my own confusion. You can help by telling me exactly what you
think a 'CreateItems' expression from entry to you would have as
a subexpression to correctly represent the following example
from the input language:
...{keywords = every keywords attribute of
# the plan-step whose pro items mention Rick}.
Note that the words "every, attribute, of, #, the, whose, items,
mention" are fixed words in the surface sysntax for this attribute
definition and furthermore that "every" maps to get-every-one and
"the" to get-the-first-one.
I think your response to this and other similar examples I may send
you will help me greatly.
Keith
---
∂TO WESCOURT (CC RICK) 14:46 6-Sept
Proposed answer
Keith,
Good hearing from you again.
I hope this partial answer will help both of us clarify what the other
expects.
First, what you mean when you say an item, M, mentions Rick:
Does this mean the atom Rick is included in M's list
of keywords, or that the string "Rick" is in the M:Text; or something totally
different?
For simplicity I will assume the first case; please correct me if I am wrong.
(This may push a lot of the necessary smarts into the algorithm which computes
that list of keywords from the english text...)
[meta-Suggestion: it would make my task easier if you could send a complete
scenario, such as the one given below. This will help me understand the
context of your question, as well as possibly disambiguate cases that I
find difficult to follow.]
Anyway, let me see if I understand your question:
Spse the following items are now in the KB:
(feel free to ignore any semantics which may have inadvertantly crept into any
of the sentences)
-*-*-*-
PlanStep#43
Pro: {Rationale#21, Rationale#47, Rationale#331}
Keywords: {waste, whatnot, widgit}
PlanStep#44
Pro: {Rationale#47, Rationale#331}
Keywords: {moose, mess, mongoose}
Rationale#21
Keywords: {road, bridge, frog}
Text: "There is a frog on the bridge over the road."
Rationale#47
Keywords: {turkey, Rick, elbow}
Text: "Right by Rick's elbow is a turkey."
Rationale#331
Keywords: {Rick, wife, clever, talk, CogSci}
Text: "Rick's wife gave a clever talk at the CogSci meeting."
-*-*-*-
At this point you want want to create a new item, say
(CreateItems
(DESCRIPTORS (ENTRY-ID ItemA)
Keywords (EVAL@ Create
(GetVal (FindFirst (EQ-PROP ITEM-TYPE Plan-Step)
(SPEC-PROP Pro Any (MEMB-PROP Keywords RICK)))
Keywords)
...
)))
RETREIVAL will return something like
((ItemA . Item#52)) once this is processed.
Item#52:Keywords will be computed as Item#52 is created, as follows:
GetVal first determines a set of item-ids (*)
from the (FindFirst ...) specification
given above, and then extracts their respective Keywords -- it is this list
which will be stored on Item#52:Keywords.
Now to find those items: FindFirst (essentially) scans thru all the items
searching for the first items which satisfies all of the conditions indicated.
The first condition,
(EQ-PROP ITEM-TYPE Plan-Step),
tells FindFirst to retrieve only items whose ITEM-TYPE is Plan-Step
-- ie this first condition prunes away everything but plansteps
(which means PlanStep#43 and PlanStep#44 in this example).
We now subset this list using the second condition,
(SPEC-PROP Pro Any (MEMB-PROP Keywords RICK)).
That is, each of these plan-steps, P, is then checked as follows:
Each S in P:Pro is then interrogated:
is Rick an element of S:Keywords?
Let's assume that PlanStep#43 is checked first.
This check involves examining each member of
PlanStep#43:Pro -- here, Rationale#21, Rationale#47, and Rationale#331.
Each of these rationales is then checked in turn, to see if their respective
Keywords include Rick.
Well, Rationale#21 fails -- its Keywords are {road, bridge, frog}, which
is deficient in Rick-iness.
Next Rationale#47 is checked -- and voila,
Rationale#47:Keywords (= {turkey, Rick, elbow})
is found to include Rick.
As the <quant> parameter of this SPEC-PROP is "Any", finding that one of
the rationale passes the MEMB-PROP test is sufficient to show that
PlanStep#43 passes the
(SPEC-PROP Pro Any (MEMB-PROP Keywords RICK)).
test.
This UNIQUE-ID, PlanStep#43, is then returned by FindFirst. GetVal takes
this value, and returns the value of its Keywords, here
{waste, whatnot, widgit}.
This set is the value stored in Item#52:Keywords.
Now, is this what you wanted? Let me give some notes on this run thru, and
follow this by some comments.
(*) Actually, FindFirst returns a single value - which is treated as if it was
a singleton set.
Notes:
1. GetVal is like GetAll, but returns just the value: here just the keywords.
Syntax: (GetVal <Match-Spec> <Prop>)
- notes
(i) only one prop is allowed (GetAll could take an arbitrary list of props)
(ii) that GetVal will cons together the value of the prop
value of each item the <Match-Spec> returns.
2. In the syntax so far, only pointer type of properties
could be evaluated at various times.
If examples like this are really needed, the syntax will have to be twiddled
to allow <Get-Spec> as a value for any property.
Will there really be examples like this?
3. The use of "the" may or may not have been what you wanted. Clearly
PlanStep#44 would also have passed these specifications, it simply had the
misfortune to occur after PlanStep#43 in this ordering... Does this worry
you -- ie am I just paranoid? (Or will this sort of thing ever really happen?)
4. Note that this assignment is a static thing -- the value is determined
only at Creation time.
Nothing happens to Item#52:Keywords
a. if the value of PlanStep#43:Keywords changes, or
b. if PlanStep#43:Pro is changed to simply {Rationale#21}, or
c. if Rick is deleted from both Rationale#47 and Rationale#331, or
d. if later we create a new PlanStep#2 whose Pro
value is {Rationale#67}, which has the appropriate Rick-ity Keywords.
The value of Item#52:Keywords will NOT change to be PlanStep#2's keywords.
You get the idea.
Eventually I'll implement something which maintains such an
invariant-over-time condition. ENTRY will be able to use this by typing
something like
(CreateItems
(DESCRIPTORS (ENTRY-ID ItemB)
Keywords (EVAL@ AllUpdates
(GetVal (FindFirst (EQ-PROP ITEM-TYPE Plan-Step)
(SPEC-PROP Pro Any (MEMB-PROP Keywords RICK)))
Keywords)
...
)))
--- other considerations/variations ---
Let's now change the example a wee bit:
Spse we want to merge together the keywords of all plan-steps whose pro items
all mention Rick -- as in
...{keywords = every keywords attribute of
# ALL plan-steps whose pro items ALL mention Rick}.
The desired Get-Spec for this is
... (EVAL@ Create
(GetVal (FindAll (EQ-PROP ITEM-TYPE Plan-Step)
(SPEC-PROP Pro All (MEMB-PROP Keywords RICK)))
Keywords))
[Hint: FindFirst went to FindAll, and the Any quantity specification is now All.]
Spse you want to use those plan-steps whose con items mention either
Rick or Barbara. Type
(GetVal (FindAll (EQ-PROP ITEM-TYPE Plan-Step)
(SPEC-PROP Con All (OR (MEMB-PROP Keywords RICK)
(MEMB-PROP Keywords BARBARA)))
Keywords))
Now try all goals or rationale whose Alt property values all exclude (ie fail to
include in their respective Keywords) Rick.
(FindAll (OR (EQ-PROP ITEM-TYPE Goal)
(EQ-PROP ITEM-TYPE Rationale))
(SPEC-PROP Alt All (NOT (MEMB-PROP Keywords RICK))))
[This can be embedded in the GetVal, or anywhere else a
<Match-Spec> can be used.]
*-*-*-*
Final comments
Stating that some item mentions Rick may be an arbitrarily difficult test,
even assuming RETRIEVAL only has to check Keywords.
We may want to store facts around Rick, which indicate that he is also
"Hayes-Roth", or "our fearless leader", or "the current head-honcho".
Creating objects to store such facts may be the solution to this problem.
[IE using a
(CreateObject Rick (Isa (AnyPerson)
Aliases ("Hayes-Roth"
"our fearless leader"
"the current head-honcho")
...))
type of command. Perhaps we should discuss this later.]
Hope this was helpful. Let me know what other questions this opened.
Russ
∂28-Sep-81 1554 GREINER at RAND-AI Specs
Changed a few of the find specs, to avoid overlay with LISP:
&,|,~ were written out, as were the quantities Any, All, None.
0[Rand-Ai]<CORE>RETRIEVAL-SYNTAX.USER.2 21-Sep-81 21:57:30, Edit by GREINER
Current version of Specification language to Retrieval, from Entry
(and from anyone else?)
Notation:
{x} means a set of one or more x's -- ie unordered
{{x}} means a list of one or more x's -- ie ordered
[x] means zero or more x's
(a . b) means (CONS a b)
( and ) are LISP parentheses...
Preliminary comment: We'll use Association Lists, not Property Lists.
ENTRY can send messages of the form
(RETRIEVAL <message-id> <To-Retr-Msg>)
where
<message-id> is a unique identifier of this message which, by convention,
will be a gensym-ed atom beginning with "E" (for Entry, the sender).
<To-Retr-Msg> ::= <Create-Item-Spec> | <Match-Spec> | <Get-Spec> | <Put-Spec>
(and possibly <Create-Obj-Spec> and <Put-Obj-Spec>).
--------
Enter new items
<Create-Item-Spec> ::= (CreateItems {<proplist>}) --0--
<proplist> ::= {<Attribute-val>}
<Attribute-val> ::= <Def-att/val> | <Undef-att/val>
<Def-att/val> ::= --1--
(POINTERS . {<ptr-item>})
| (DESCRIPTORS . {<Self-desc>})
| (KEYWORDS . {<token>})
*** | (HISTORY . (<past-Item-Id-and-reason> <future-Item-Id>))
| (STATUS . <status-val>)
| (TYPE . <type-val>)
| (NAMES . {<token>}) --2--
| (TEXT . <sent-string>)
| (SYNTAX . <case-frame-parse>)
*** <Undef-att/val> ::= (<Undef-att> . <value>)
<Self-desc> ::= --3--
(ENTRY-ID . <Item-Id> ) --4--
| (CREATION-DATE . <creation-date>)
| (AUTHOR . <creator>)
<creation-date> ::= <TIME-STAMP>
<creator> ::= <USER-NAME>
*** <past-Item-Id-and-reason> ::=
*** (<Item-Id> <reason-for-change-Item-Id>)
*** | NIL
*** <reason-for-change-Item-Id> ::= <Item-Id>
*** <future-Item-Id> ::= NIL | <Item-Id>
<pointer-val> ::= (<Pointer> . { <item-reference> })
<Pointer> ::= Sub | -Sub | Req | -Req | Cor | Dep | -Dep --5--
Alt | -Alt --6--
Pro | -Pro | Con | -Con
<item-reference> ::=
(<Item-Id>)
| <Evaled-Match-Spec>)
<status-val> ::= ACTIVE | INACTIVE --7--
| <Evaled-Get-Spec>
<type-val> ::= REASON | ASSUMPTION | RULE | --8--
MASTER | GOAL | SPECIFICATION | TASK
<Evaled-Match-Spec> ::=
(EVAL@ <time-for-eval> <Match-Spec>) --9--
<Evaled-Get-Spec> ::=
(EVAL@ <time-for-eval> (GetVal <Genl-Match-Spec> <Prop>))
<Genl-Match-Spec> ::= -10--
<Match-Spec> | (QUOTE { <Item-Id> })
<time-for-eval> ::= Create-Time | Retrieval-Time
| End-Of-Create -11--
| Always | AllUpdates
<token> ::= <ATOM> | {{ <ATOM> }} | <Evaled-Get-Spec>
<sent-string> ::= {{ <ATOM> }}
<case-frame-parse> ::= { (<case-name> . <token>)
| (<case-name> . <case-frame-parse>) }
<case-name> ::= SUBJECT | VERB | OBJECT | PREPOSITION | REL | ADVERB |
ADJECTIVE | ...
Notes
The "***"s refer to things we haven't implemented yet.
--0-- This function will return, as a confirmation, a list of the form
( (<entry1 . unique1) (<entry2 . unique2) ... (<entryN . uniqueN) )
where each entryI is the value of the ENTRY-ID sent over for some item,
and uniqueI is the UNIQUE-ID Retrieval has assigned this item.
--1-- We will also say
<Def-att/val> ::= (<Def-att> . <value>),
where <Def-att> ::= POINTERS | DESCRIPTORS | KEYWORDS
| HISTORY | STATUS | TYPE | NAMES | TEXT | SYNTAX
--2-- This is what Barbara called SUBJECT, I think. Note Keith wants that
term for his syntactic tree...
--3-- We will say
<Self-desc> ::= (<Self-att> . <value>)
where <Self-att> ::= ENTRY-ID | CREATION-DATE | AUTHOR
(see note --1-- above)
--4-- not UNIQUE-ID -- Only Retrieval can generate UNIQUE-IDs!
--5-- This list will probably undergo much change, at least at first.
See the file [Rand-Ai]<CORE>LEGAL.VALUES for current list.
--6-- Isn't Alt its own inverse?
--7-- These used to be IN and OUT, but ELLIE didn't like that.
--8-- This list will probably undergo much change, at least at first.
See the file [Rand-Ai]<CORE>LEGAL.VALUES for current list.
--9-- This will be defined in the next part.
-10-- This case could be handled using (FindAll (Gen '(item1 ... itemN))).
-11-- Currently only End-of-Create is currently used.
----------
Find existing items
<Match-Spec> ::= (<Find?> {<spec>})
<Find?> ::= FindFirst | FindAll | FindOnly --0--
<spec> ::= (Gen <sexpr>) --1--
| <term>
| (OR-SPEC . {<spec>})
| (AND-SPEC . {<spec>})
| (NOT-SPEC <spec>)
<term> ::= (EQ-PROP <Prop> <val>) --2--
| (MEMB-PROP <Prop> <val>)
| (MATCH-PROP <Prop> <pattern>)
| (SPEC-PROP <Item-Prop> <quant> <spec>)
| (PRED-PROP <Prop> <fn>)
| (PRED <fn>)
<Item-Prop> ::= <Prim-Prop>
| (Composition {<Item-Prop>}) --3--
| (Unioning {<Item-Prop>})
| (Intersection {<Item-Prop>})
| (Starring <Item-Prop> )
| (Plussing <Item-Prop> )
<Prim-Prop> ::= <Pointer>
<Prop> ::= <Item-Prop> | <Def-att> | <Self-att> | <Retrieval-att>
*** | <Undef-att>
<Retrieval-att> ::= UNIQUE-ID
<val> ::= <unevaled-constant> | <Evaled-Get-Spec>
<quant> = ANY-SUB | ALL-SUB | NO-SUB --4--
<pattern> is something the InterLisp pattern matcher accepts.
This is applied to the value of that <Prop>.
<fn> evaluates to a predicate function
<sexpr> is a LISP s-expression, to be evaluated
NOTES
--0-- The FindFirst command returns a single UNIQUE-ID
-- corresponding to the first (and presumably only) item
which satisfies these constraints, or NIL.
FindAll returns a list of the UNIQUE-IDs of all items which qualify,
or NIL.
FindOnly returns a single UNIQUE-ID, but complains if more than one
item satisfy this request.
--1-- There is also a way of generating items, rather than just pruning:
GEN - the S-expression <sexpr> is evaluated, and its result is a
list of item unique-ids.
--2-- These are testers: An item, I, passes the test implied by the
condition <term> when (by (CAR <term>) ):
EQ-PROP - the value of the I:<Prop> is EQUAL <val>
MEMB-PROP - the value of the I:<Prop> includes <val>
MATCH-PROP - <val> matches the value of the I:<Prop>, using the
InterLisp pattern matcher.
SPEC-PROP - the value of the I:<Item-Prop> is a list of pointers to
other items. These items are then subjected to the test implied
by <spec>. Item I passes this overall <term> test if any of
these pointed-to-items pass the imbedded <spec>, when <quant>
is Any. When <quant> is All, they all must pass. (The other
<quant>s are handled similarly. See Note --5-- below.)
PRED-PROP - the value of I:<Prop> satisfies the predicate <fn>.
PRED - Here the function <fn> is applied to entire item (actually
its unique id).
--3-- These properties are particularly useful for computing ramifications,
needed for the general retrieval mentioned below.
This list of slot combiners is NOT meant to be exhaustive -- but rather
to include the sort of general properties a ramifier might need.
--4-- If Any, this predicate succeeds when any of the list of values
satisfies the predicate, <fn>;
when All, each value must satisfy <fn>,
None means all of the values must fail.
I may later get fancier, and allow numeric ranges, or statements that
as many of these as those, or ...)
----------
Get some property of some item
<Get-Spec> ::= (Get <Item-Id> <Prop>) --0--
| (GetAll <Genl-Match-Spec> {<Prop>}) --1--
| (GetVal <Genl-Match-Spec> <Prop> ) --2--
NOTES
--0-- The Get command returns the value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- GetAll first finds the unit(s) indicated by "evaluating" <Match-Spec>,
it then retrieves the values of each of their properties, <Prop>.
The value returned is
((Id1 v11 v12 ... v1N) (Id2 v21 v22 ... v2N) ... (IdM vM1 vM2 ... vMN))
where IdI is the I-th id returned by <Match-Spec>, and vIJ is the value
of the Jth property mentioned in the {<Prop>} list, of that Ith item.
(If this <Match-Spec> returned only one item, then GetAll pretends it
got the list of that single element.)
--2-- GetVal is like GetAll, but returns simply
(v11 v12 ... v1N v21 v22 ... v2N ... vM1 vM2 ... vMN)
[using the notation used above].
Note it concatenates the values together.
Ramification is nothing special now: One can specify the <Prop>
(Starring Sub) - to get all Subs, their Subs, and so on. On
talk about (Composition Sub Alt) - to get all Subs of this item's Alts;
etc.
Below I will discuss how to create new types of properties, defined as some
combination of existing properties.
----------
Modify some property of some item
<Put-Spec> ::= (<Simple-Change> <Item-Id> <Prim-Prop> <value> <Why>) --0--
| (<Mult-Change> <Match-Spec> <Prim-Prop> <value> <Why>) --1--
<Simple-Change> ::= Put | Add | Delete --2--
<Mult-Change> ::= PutAll | AddAll | DeleteAll --3--
<Why> ::= <reason-for-change-Item-Id> --4--
NOTES
--0-- These commands return the new value of this property of the item associated
with the UNIQUE-ID <Item-Id>.
--1-- These first finds the unit(s) indicated by "evaluating" the <Match-Spec>,
and then modify the values of their respective <Prim-Prop> properties.
The value returned is
((Id1 v1) (Id2 v2) ... (IdM vM))
where IdI is the I-th id returned by Match-Spec, and vI is the new
value of that property.
(If this <Match-Spec> returned only one item, these functions pretends it
got the list of that single element.)
--2-- Put stores a new value in the <Prim-Prop> property of this item;
Add adds this new value in this property of the item;
and Delete deletes this value in this property of the item.
--3-- The ___All functions do just what the corresponding ___ function did,
but does so to each result of the Match-Spec.
--4-- Why points to an item which tells why this change was made.
----------
Still to do:
1) Hammer out a syntax for defining new properties. Perhaps
(CreateObject <name> ({<slot-val>})), so we might say
(CreateObject Sub* ((Isa . (AnyPointer)) (HighLevelDefn . (Starring Sub))))
-or-
(CreateObject DueDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
[Yes, I know the names seem arbitrary -- we could have a host of aliases
and ways of chopping strings into smaller chunks, if you prefer.]
I'll call this still undefined specification <Create-Obj-Spec>.
Once this is done, we can consider <Put-Obj-Spec>,
and possible <Get-Obj-Spec>.)
2) How to send back and form messages, especially to confirm a new type of object
or slot; and to figure out what to do with it.
Perhaps Retrieval could send something like
(I never heard of "StartDate"; based on the context I assume it is like DueDate,
and so I propose you send back:
(CreateObject StartDate ((Isa . (AnyPrimitiveSlot AnyRATALEFn))
(RangeType . (FSingleton (StringType (*Test TimeStamp))))
(MakesSenseFor . (TypicalPlan-Step))))
)
On receiving this, ENTRY could then ask the user what he meant, and
possibly just send back a confirming "Yep", which will serve as if
Entry had sent in that entry; otherwise Entry would be forced to either
retract that last item, or to first send over a new CreateObject statement,
which Retrieval would process before returning to its suspended
offending task.
Retrieval might also send a message like
(Did you mean DueDate when you said DuDate?),
etc.
-----
We never used the syntax:
(a..b) means (APPEND a b) --
hence ((p1 v1)..(p2 v2 p3 v3)) gives (p1 v1 p2 v2 p3 v3)
-------